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ABSTRACT 

Results  of  tasks  performed  by  ARINC  Research 
Corporation  in  support  of  the  Performance  and  Reliability 
Reporting  (PARR)  system  for  Torpedo  Mk  48  over  the 
past  two  years  are  summarized.  The  Corporation  provided 
a broad  range  of  engineering  services  that  contributed  to  the 
continuing  development  and  refinement  of  the  PARR  system. 
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ABBREVIATIONS 


1 

ADM 

"American  Dream  Machine"  (Lear-Seiglcr,  Inc.) 

1 

ADP 

Automatic  data  processing 

1 

ADPE 

Automatic  data  processing  equipment 

.! 

ADS 

Automatic  data  system 

1 

Ascn 

American  Standard  Code  for  Information  Interchange 

'4 

ASW 

Anti-submarine  warfare 

11 

fl 

AUTOVON 

Automatic  Voice  Network 

r' 

1 

BCD 

Binary  coded  decimal 

i 

i 

BISYNC 

Bisynchronous 

t 

bpi 

Bits  per  inch 

1 

1 

bps 

Bits  per  second 

fi 

CDC 

Control  Data  Corporation 

CPU 

Central  processing  unit 

: 

COMCOP 

Communications  cop  (director) 

[ ’ 

1 i 

Cps 

Characters  per  second 

li 

CRT 

Cathode  ray  terminals 

f.i 

i 

EIA 

Electronic  Industry 

1 

EOT 

End  of  transmission 

t, 

1 

1 1 

ETX 

End  of  text 

1 1 
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GSA 

General  Services  Administration 

■ -i 

HCP 

Hard  copy  printer 

, T 

IMA 

Intermediate  maintenance  activity 

'1 

r 

ips 

Inches  per  second 

r 

i 

I 

JCS 

Joint  Chiefs  of  Staff 

LED 

Light- emitting  diode 

MRF 

Minor  repair  facility 

MTC 

Magnetic  tape  cassette 

NAD 

Naval  Ammunition  Depot 

NAVORD 

Naval  Ordnance  (Systems  Command) 

NSSF 

Naval  Submarine  Support  Facility 

NTS 

Naval  Torpedo  Station,  Wash. 

L 


J 
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NUSC 


r 


■SPSHB® 


Naval  Undenvater  Systems  Center 


OEM 

Original  equipment  manufacturer 

PAIU 

PARR-AUTOVON  Interface  Unit 

PARR 

Performance  and  Reliability  Reporting 

QEEL 

Quality  Evaluation  and  Engineering  Laboratory 

RJE 

Remote  job  entry 

RRC 

Repair  record  card 

RTT 

Remote  transmission  terminal 

SXjBBASE 

Submarine  Base 

UT 

User  terminal 

VA 

Volt-amperes 

WATS 

Wide  Area  Telephone  System 
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1 

INTRODUCTION 


Since  April  1972,  ARINC  Research  Corporation  has  been  assisting  the  U.  S, 
Naval  Torpedo  Station,  Keyport,  Wash. , in  the  implementation  and  continuing  refine- 
ment of  the  Performance  and  Reliability  Reporting  (PARR)  system  for  Torpedo  Mk  48 
and  associated  equipments.  This  assistance  has  been  in  the  form  of  both  specific 
services  to  meet  immediate  requirements  or  problems,  and  system  studies  having 
long-range  implications. 

During  the  period  of  the  Corporation's  assistance,  the  PARR  system  has 
expanded  from  a batch-reporting  toward  an  on-line  system,  in  which  the  delay  time 
between  the  occurrence  and  reporting  of  events  will  be  measured  in  days  or  hours 
instead  of  weeks.  While  this  transition  is  not  yet  complete,  significant  accomplish- 
ments have  been  made  toward  that  objective,  some  of  which  are  described  in  this 
report. 

The  assistance  provided  by  ARINC  Research  over  the  past  three  years  has  been 
under  two  contract:-  Under  the  initial  contract  (N00406-70-C-0488),  the  Corporation 
developed  a step-by-step  implementation  plan  for  incorporating  the  PARR  communi- 
cations capability  into  the  NTS  computer,  for  locating  and  structuring  the  PARR  data 
files,  and  for  evaluating  and  selecting  an  optimum  remote  terminal  configuration.  In 
addition,  the  Corporation  generated  a system  plan  for  the  continued  development  of 
PARR  over  the  period  1973  through  1978,  in  which  system  capability  will  be  matched 
in  an  evolutionary  manner  with  expected  demands. 

Under  the  present  contract  (N0040G-73-C-0631) , ARINC  Research  has  provided 
follow-on  studies  contributing  to  the  further  development  of  the  PARR  system.  These 
studies  were  conducted  under  15  general  task  headings,  as  follows; 

Task  Type 


No. 

Topic 

Start  Date 

End  Date 

Report 

1 

PARR  System  Plan 

4/1/73 

6/30/73 

Formal 

2 

Data  Feedback  System 

4/1/73 

11/19/73 

Letter 

3 

Users  Manual 

4/1/73 

8/31/74 

Letter 

4 

Torpedo  Mk  48  Support 
Equipment  Reporting 

4/1/73 

9/5/73 

Letter 

5 

Mobile  ASW  Target  Reporting 

4/1/73 

6/30/73 

Letter 

6 

Configuration  Accounting  for 
Torpedo  Mk  48  Support 
Equipment 

4/1/73 

8/6/73 

Letter 

7 

Target  Data  System  Reporting 

8/1/73 

2/28/75 

Informal 
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Task 

No. 

Topic 

Start  Date 

End  Date 

Type 

Report 

8 

Factory  Acceptance  Reporting 

8/1/73 

Cancelled 

9 

Preproduction  and  Periodic  Test 
Reporting 

8/1/73 

11/11/73 

Letter 

10 

Communication  System  Studies 

8/1/73 

2/28/75 

Formal 

11 

PARR  Procedures  Manual 

8/1/73 

2/28/75 

Informal 

12 

Mk  48  Torpedo  Support  Equip. 
Deficiency  Data  Collection 

8/1/73 

9/30/74 

Letter 

13 

ADS  Development  Plan 

1/8/73 

4/31/74 

Informal 

14 

Dedicated  ADP  Requirements 

4/irj/74 

2/1/75 

Tech  Note 

15 

NUSC  Reporting  Requirements 

5/16/74 

11/7/74 

Formal 

Some  of  these  tasks  comprised  numerous  subtasks,  and  a great  quantit3'  of 
documentation,  in  various  forms,  was  delivered  to  NTS/Keyport  reporting  the 
results.  This  final  report  under  the  contract  will  briefly  note  the  work  accomplished 
under  each  task,  and  serve  as  a reference  listing  of  the  submittals  in  which  the 
detailed  results  appear. 
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2 

TASK  DESCRIPTION 


2,1  TASK  1:  PARR  SYSTEM  PLAN 

The  PARR  System  Plan.  ARINC  Research  Publication  1(512-01-1-1240  (July 
1973),  addresses  the  status  of  the  PARR  system  in  early  1973  and  the  projected  evolu- 
tion of  that  system  in  the  foreseeable  future,  A five-year  profile  of  expected  users 
and  their  demands  is  developed,  and  guidelines  are  presented  for  the  actions  and 
resources  required  to  meet  these  demands.  Also  included  is  a summary  of  safe- 
guards necessary  to  protect  the  system  against  intentional  and  unintentional 
degradation  of  integrity. 

As  a starting  point,  the  System  Plan  assumes  the  implementation  of  a remote 
terminal  capability  for  input  and  retrieval  of  information  after  the  PARR  system  has 
been  in  operation  for  two  years  (early  1975),  The  remote  terminals  will  provide  for 
a basic  and  desirable  change  in  PARR  reporting.  In  June  1973  the  PARR  system 
served  about  30  users  requesting  a monthly  average  of  10  reports  containing  some 
3000  printed  lines.  The  projected  system  would  serve  many  more  users  requesting 
smaller,  more  specific  reports  — the  1978  projection  is  more  than  100  users  request- 
ing more  than  1000  reports  per  month,  with  each  report  being  about  20  lines  (to  fit  a 
remote-terminal  display  screen), 

PARR  system  users  in  the  early  years  (through  1975)  will  be  predominately 
administrative  and  managerial  personnel.  However  the  balance  is  expected  to  swing 
toward  maintenance  line  users  in  1976  as  they  continue  to  increase  in  number  while 
the  quantity  of  administrative  users  remains  relatively  constant. 

According  to  the  System  Plan  the  following  development  chronology  can  be 
anticipated: 

a.  Installation  of  a commimications  front-end  in  late  1974 

b.  Development  of  independent  data  and  communication  processors  in  1975 

c.  Expansion  of  the  computer  complex  with  increasing  demand  until  early 
1976 

d.  Continuation  of  remote  site  development  into  early  1977, 

Guidelines  were  generated  for  the  use  of  communication  facilities,  including 
AUTOVON,  direct  distance  dialing,  WATS,  and  private  lines,  as  dictated  by  usage. 
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2.2  TASK  2:  DATA  FEEDBACK  SYSTKM 


In  Task  2,  ARINC  Research  performed  a study  to  demonstrate  the  utilization  of 
a timely  shop-reliability  feedback  system  from  the  torpedo  preparation  sites  at  Cape 
Canaveral,  NAD/Oahu,  SUBBASE/New  London,  and  Goiild/Cleveland  to  NTS/Keyp<irt. 
Results  of  this  study  were  submitted  to  NTS/Keyport  in  a letter  report  entitled, 

"Study  of  Utilization  of  Shop  Reliability  Feedback  System"  (19  November  1973). 

The  operational  concept  developed  in  the  implementation  outline  given  in  the 
PARR  System  Plan  (see  Section  2.1)  was  reviewed  for  adequacy,  and  tests  were  per- 
formed and  operation  monitored  at  sites  where  PARR  equipment  was  installed.  The 
data-collection  concept  in  the  PARR  system  is  to  record  the  data  generated  at  opera- 
tional sites  onto  tape  cassettes,  using  an  electronic  terminal  independent  of  a central 
computer.  While  this  procedure  does  not  entirely  replace  the  paperwork  process  of 
filling  in  report  forms,  it  doijs  permit  capture  of  information  at  the  point  of 
generation  before  mailing  and  editorial  review.  Daily,  or  more  often  if  required,  the 
data  on  the  tape  cassette  can  be  transmitted  over  a telephone  line  to  the  central  com- 
puter site  for  immediate  processing.  In  this  manner,  data  from  a remote  site  may 
generally  be  made  available  within  one  day  of  a reportable  event.  Since  the  data  are 
raw  and  prone  to  some  error,  transmission  is  followed  up  by  normal  review  of  the 
"paper"  report,  in  context  with  other  reports,  and  the  computer  entry  corrected  as 
required. 

The  error  rate  during  data  communication  was  measured,  and  the  effect  of  this 
rate  on  data  quality  was  estimated.  It  was  concluded  that  an  acceptable  error  rate  of 
1 bit  in  100,000  can  be  achieved  by  regular  attention  to  equipment  testing  and  mainte- 
nance, and  implementation  of  error  detection  measures.  This  error  rate  is 
approximately  equal  to  one  incorrect  character  in  five  filled-in  report  forms,  or  less 
than  normal  operator  error. 

In  transmission  tests  between  Honolulu  and  NAD/Oahu  to  NTS/Keyport,  it  was 
fovmd  that  when  transmission  was  acceptable  for  a short  time  period  (less  than  a 
minute),  it  was  likely  to  remain  aeceptable  for  about  15  minutes.  This  is  an 
engineering  estimate  with  no  stated  statistical  accuracy. 


2.3  TASK  3:  USERS  MANUAL 

Under  Task  3,  ARINC  Research  studied  the  existing  P ARR  operating  procedures 
and  the  operational  context  in  which  they  were  developed,  and  then  generated  a users 
manual  containing  recommended  procedures  and  documentation.  As  defined  in  the 
original  task  statement  of  1 April  1973,  the  users  manual  was  to  be  ". . . . for  use  by 
PARR  personnel,  outlining  data  flow,  review  criteria,  input  procedures,  and  output 
selection  criteria  covering  data  received  from  or  reported  to  both  local  and  off-station 
sources. " 

As  work  on  the  manual  progressed,  the  emphasis  was  changed  from  PARR 
personnel  to  potential  administrative  users  of  PARR  data.  Accordingly,  the  amount 
of  descriptive  information  on  the  system  was  expanded  (from  the  original  intent)  into 
a full  volume;  with  the  operator-oriented  access  procedures  and  input/output 
descriptions  appearing  in  a second  volume. 

Work  on  the  users  manual  was  stopped  by  NTS  prior  to  its  completion,  and  a 
partially  edited  draft  was  delivered  to  NTS  in  January  1974.  Editorial  refinement  of 
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the  narrative,  and  technical  updating  of  the  appendix  material,  was  accomplished  by 
NTS  for  the  production  of  the  final  user's  manual. 

The  draft  manual  submitted  by  AHINC  Research  was  entitled  "User's  Manual 
for  Torpedo  Mk  48  RAHR  Data  System",  and  comprised  two  volumes.  Volume  I pre- 
sented a general  introduction  (Section  1);  a summary  of  the  PARR  program  (Sec- 
tion 2);  a detailed  description  of  the  system  (Section  3);  and  general  access  procedures 
(Section  4).  The  system  description  included  data  collection,  review,  analysis,  and 
processing:  automation  of  the  data  system;  and  data  input,  storage,  and  retrieval 
procedures.  Appendixes  covered  decision  criteria  and  examples  of  output.  Volume  II 
summarized  the  PARR  system  products  and  described  the  access  procedures  in 
detail. 


2.4  TASK  4:  TORPEDO  MK  48  SUPPORT  EQUIPMENT  REPORTING 

The  engineering  analysis  performed  under  this  task  was  directed  toward  using 
the  PARR  system  for  reporting  on  Torpedo  Mk  48  support  equipment.  The  following 
was  accomplished  under  this  task: 

a.  Recommendations  were  prepared  concerning  implementation  of  support 
equipment  reporting,  and  assistance  was  provided  in  developing  a pro- 
posed instruction  manual  and  format  for  data  collection. 

b.  Recommendations  were  provided  concerning  data  review  and  input 
procedures  for  supporting  equipment  maintenance  and  deficiency/ 
logistics  data  reporting. 

c.  Support  equipment  deficiency  reports  were  reviewed  and  categorized  on 
a daily  basis. 

d.  Four  data  summaries  were  submitted  for  incorporation  into  the  PARR 
Monthly  Summary  Report  prepared  by  NTS  for  the  NAVORD  Mk  48 
Project  Office  (PMO  402). 

Details  appear  in  an  ARINC  Research  report  entitled,  "Mk  48  Support  Equip- 
ment Analysis  and  Review,  Task  04  Final  Report",  dated  September  5,  1973. 


2.5  TASK  5:  MOBILE  ASW  TARGET  REPORTING 

As  specified  in  Task  5 of  the  contract,  ARINC  Research  conducted  a study  to 
establish  and  document  reporting  procedures  for  Mobile  ASW  Target  Mk  30  Mod  1. 
The  reporting  procedures  encompassed  system  reliability,  test  equipment,  docu- 
mentation, and  configuration  reporting;  with  all  reporting  required  to  be  compatible 
with  the  Torpedo  Mk  48  PARR  system. 

At  the  request  of  the  Target  Program  Manager,  the  study  was  expanded  to 
include  Target  Mk  27.  It  was  found  that  the  Target  Mk  30  procedures  were,  with 
minor  modifications,  fully  applicable  to  Target  Mk  27  reporting. 

All  elements  necessary  for  reporting  on  both  target  systems  were  developed  in 
conformity  with  the  requirements  of  the  study,  and  have  been  made  available  to  NTS. 
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Details  of  the  study  appear  in  an  ARINC  Research  letter  report  entitled,  "Mobile  ASW 
Target  Mark  30,  Mod  1 Reporting,  Task  05  Final  Report",  August  28,  1973. 


2.6  TASK  6:  CONFIGURATION  REPORTING  FOR  TORPEDO  MK  48 

SUPPORT  EQUIPMENT 

Ground  rules  for  incorporating  Torpedo  Mk  48  support  equipment  into  the 
PARR  configuration  reporting  system  were  generated  under  Task  6.  This  task  was 
performed  concurrently  with  Task  4,  the  development  of  a support-equipment  PARR 
reporting  form  and  a proposed  NAVORD  instruction  (see  Section  2.4). 

Findings  of  Task  6 were  as  follows: 

a.  A configuration  tracking  system  can  be  implemented  for  Torpedo  Mk  48 
support  equipment.  This  system  would  allow  retrieval  of  part  number 
(or  alteration  status)  and  serial  number  listings  for  significant 
support  equipment  items  at  each  Torpedo  Mk  48  support  activity. 

b.  The  configuration  tracking  system  would  use  the  proposed  PARR  data 
collection  form  (NAVORD  4790)  to  provide  update  information. 

Results  of  the  study  are  presented  in  the  ARINC  Research  letter  report,  "Mk  48 
Support  Equipment  Configuration  Study",  27  July  1973. 


2.7  TASK  7:  TARGET  DATA  SYSTEM  REPORTING 

In  accordance  with  Task  7,  ARINC  Research  developed  and  documented  recom- 
mended standard  procedures  for  incorporating  reliability,  deficiency,  and  configura- 
tion data  for  Mobile  ASW  Target  Mk  30  Mod  1 into  the  PARR  system.  Included  was  a 
standard  procedure  for  the  acquisition,  handling,  and  entering  into  the  PARR  system 
of  repair  information  from  the  manufacturer  and  the  depots. 

Following  implementation  of  these  recommended  procedures,  the  PARR 
Management  Information  System  was  reviewed  and  audited  during  the  Target  Mk  30 
Mod  1 Predeployment  Test  Program  commencing  in  August  1974.  Upon  completion 
of  the  audit,  recommendations  were  generated  for  the  expansion  of  target  system 
reporting  to  encompass  mobile  targets  Mark  30  Mod  0 and  Mark  27  Mod  0.  The 
impact  of  increased  target  reporting  was  examined  and  a preliminary  plan  was 
recommended  for  implementing  increased  PARR -target  reporting. 

Documentation  issued  by  ARINC  Research  under  this  task  included  the 
following: 

a.  NAVORD  OD  45291,  Technical,  Manual,  Mobile  ASW  Target  Mark  30 
Mod  1 System  Information  Analysis  System  Handbook  for  Performance, 
Reliability,  Maintainability,  Configuration,  Inventory,  and  Deficiency 
Reporting  (June  1974) 

b.  Memorandum,  Mobile  ASW  Target  Mark  30  Mod  1 System  Performance 
and  Reliability  Reporting  (PARR-Target)  Procedures  Manual  (5  June  1974) 
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c.  Guidance  instructions,  Mobile  Target  Input  Scoring  Form  I,  "Pro- 
cedures and  Criteria  for  Preparing  PAIIR  Score  Summary  of  Monthly 
Target  Performance  Summary  Report"  (July  1974) 

d.  Interim  report,  Audit  of  the  PARR  Information  and  Analysis  System 
During  the  Mobile  ASW  Target  Mark  30  Mod  1 Pre-deployment 
Program  (30  September  1974) 

e.  Technical  note.  Procedures  for  Acquisition,  Handling,  and  Entering 
into  PARR  System  of  Repair  and  Failure  Analysis  Data  for  Target  ^ 30 
Mod  1.  ARINC  Research  publication  W4-ir)12-TN03  (Ocrober  1974) 

f.  Card  file.  Bibliography  of  Reference  and  Source  Data  for  the 
Target  Mark  30  Mod  1 (November  1974) 

g.  Technical  note.  Procedures  for  Acquisition,  Handling,  and  Entering 
into  PARR  System  of  Repair  and  Failure  Analysis  Data  for  Target 
Mk  30  Mod  l/O  at  Port  Allen,  Kauai  Pending  Activation  of  the  Remote 
Terminal  and  Hiring  and  Training  of  a Terminal  Operator.  ARINC 
Research  publication  W4-1612-TN03  (November  1974) 

h.  Attachment  I to  NAVORD  OD  46291,  Change  1,  Mobile  ASW  Target 
Systems  Mark  27  and  30,  Maintenance,  Deficiency,  and  Configuration 
Data  Collection  Procedures  Manual  (February  1975) 

i.  Memorandum,  Audit  of  PARR  Information  and  Analysis  System  During 
Mobile  ASW  Target  Mark  30  Mod  1 Pre-deployment  Program 
(February  1975) 

2.  8 TASK  8;  FACTORY  ACCEPTANCE  REPORTING 

Shortly  after  the  initiation  of  this  task,  NTS  redirected  ARINC  Research’s 
efforts  to  other  tasks  vmder  the  contract.  Subsequently,  this  task  was  cancelled. 

2.9  TASK  9:  PREPRODUCTION  AND  PERIODIC  TEST  REPORTING 

ARINC  Research  conducted  a study  to  determine  the  feasibility  of  incorporating 
Torpedo  Mk  48  component  preproduction  and  periodic  production  test  data  into  the 
PARR  system.  On  the  basis  of  this  study,  recommendations  were  generated  for 
establishing  a reporting  program  for  component  test  data. 

This  investigation  entailed  the  development  of  a flow  diagram  depicting  the 
sequence  of  events  during  component  testing  at  QEEL  (Quality  Evaluation  and 
Engineering  Laboratory,  Naval  Torpedo  Station);  identifying  at  which  points  in  the 
event  sequence  that  PARR  data  forms  are  needed;  a review  of  the  current  PARR  form 
and  format  for  the  incorporation  of  component  test  data;  a review  of  QEEL  test  report 
types  to  identify  their  significant  data  elements;  and  determining  the  workload 
required  to  incorporate  the  current  backlog  of  component  test  data  into  the  PARR 
system. 

Details  of  the  study,  including  the  recommendations  for  implementing 
component  data  reporting,  appear  in  an  ARINC  Research  letter  report  entitled,  "Study 
of  PARR  Reporting  for  Component  Preproduction  and  Periodic  Test  Data".  This 
report  was  submitted  to  NTS  under  a cover  letter  dated  October  11,  1973. 
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2.10  TASK  10;  COMMUNICATION  SYSTEM  STUDIES 

Task  10  under  the  contract  consisted  of  a number  of  subtasks,  primarily  of  a 
consulting  nature.  The  subtasks  were  directed  toward  providing  quick- reaction  solu- 
tions to  problem  areas  relating  to  PARR  communications.  Therefore  the  reports 
under  most  of  the  subtasks  were  expediently  prepared  and  informally  submitted. 
Appendix  A of  this  report  presents  refined  and  retyped  versions  of  these  informal  sub- 
mittals, which  will  be  referenced  as  appropriate  in  the  following  brief  descriptions  of 
subtasks. 

2.10.1  Gould  Network  Monitoring 

Gould  Ocean  Systems  Division,  manufacturer  of  Torpedo  Mk  48,  has  established 
a data  collection  and  dissemination  network  with  a central  facility  at  Gotild  manufac- 
turing headquarters  (Cleveland,  Ohio)  and  remote  stations  at  the  minor  repair 
facilities.  Under  Task  10a,  ARINC  Research  reviewed  Gould  plans  and  developed 
recommended  techniques  for  interfacing  the  PARR  and  Gould  networks.  The  objective 
of  the  monitoring  and  interfacing  has  been  to  provide  for  timely  retrieval  of  repair 
record  card  (RRC)  data  and  card-level  configuration  data. 

The  first  general  data-coordination  meeting  between  Gould  and  the  Navy  (repre- 
sented by  NAVORD,  NUSC,  and  NTS,  with  ARINC  Research  as  adviser)  was  held  in 
Cleveland  on  30-31  May  1973.  At  that  meeting,  Gould  discussed  its  data  collection 
and  dissemination  plans,  and  the  Navy  representatives  described  the  PARR  system. 
The  most  significant  conclusion  from  the  meeting  was  that  the  interface  between  the 
two  systems  would  be  the  PARR  terminals  at  the  common  IMA  locations.  As  result  of 
this  decision,  the  Gould  terminals,  manufactured  by  Nixdorf,  were  programmed  by 
Nixdorf  and  Gould  to  emulate  the  PARR  terminals,  manufactured  by  Hazeltine. 

Actual  procurement  of  hardware  for  the  Gould  network  was  delayed  until 
November  1973.  ARINC  Research  maintained  periodic  contact  with  Gould  throughout 
this  period,  clarifying  operating  concepts  and  technical  parameters  so  that  develop- 
ment could  proceed  with  maximum  compatibility  with  the  PARR  system. 

In  December  1973,  ARINC  Research  requested  the  Chicago  office  of  Hazeltine 
to  loan  a Hazeltine  terminal  to  the  Chicago  office  of  Nixdorf  for  diagnostic  testing. 

The  terminal  was  made  available  in  March  1974.  At  the  end  of  March  a significant 
milestone  was  reached  when  communication  was  demonstrated  between  the  Nixdorf 
and  Hazeltine  terminals  in  Cleveland. 

Two  Nixdorf  terminals  were  installed  in  May  1974  at  Gould  MRFs  in  Keyport  and 
Oahu.  In  June,  observations  of  some  tests  conducted  by  Gould  indicated  satisfactory 
exchange  of  information,  but  at  a low  level  of  throughput  (between  10  and  20  characters 
per  second).  Suggestions  were  offered  to  improve  the  throughput  to  50  characters 
per  second  or  300  words  per  minute,  a minimum  acceptable  throughput  considering 
the  short  message  length  (72  characters)  and  necessary  line  turnaround  time. 

2. 10.  2 NAVORD  Link 

A requirement  exists  to  transfer  a moderate  amount  of  data  between  NTS/ 
Keyport  and  NAVORD/Washlngton,  D.  C.  In  June  1973  an  experimental  link  was  estab- 
lished by  using  a Control  Data  Corporation  (CDC)  model  200  user  terminal  at  Keyport 
to  transfer  data  into  a CDC  computer  in  Washington,  and  then  retrieving  the  data  on  a 
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DATA  100  Corporation  model  78  terminal  at  NAVORD.  This  approach  was  not  as 
effective  as  desired,  and  ARINC  Research  was  directed  by  NTS  (as  Task  10b)  to  study 
alternative  possibilities.  ARINC  Research  made  two  analyses,  one  in  November  1973 
and  an  update  in  April  1974.  The  resulting  reports  are  included  in  Appendix  A-1. 

Four  alternatives  are  defined  in  the  first  report,  given  the  constraints  of 
available  equipment.  The  Honeywell  (PARR  central  site)  computer  could  be  modified 
to  accommodate  one  of  the  DATA  100  terminal  modes  of  communication.  Alternatively, 
the  DATA  100  terminal  could  be  programmed  to  emulate  either  the  Honeywell  com- 
puter or  the  Hazeltine  remote  terminal,  in  either  its  PARR  or  non-PARR  configuration. 
None  of  these  approaches  was  judged  to  be  entirely  satisfactory,  since  major  pro- 
gramming changes  would  be  required. 

In  the  second  analysis,  the  Mohawk  2400  terminal  was  considered.  It  was 
verified  that  both  terminals  could  emulate  the  IBM  2780  terminal,  thereby  communi- 
cating with  each  other.  The  IBM  2780  is  a card-handling  terminal  using  the  Extended 
Binary  Coded  Decimal  Information  Code  (EBCDIC)  in  a symmetrical  communication 
line  protocol.  A consequence  of  this  emulation  requirement  is  discussed  in  the  sec- 
ond report  in  Appendix  A-1,  as  is  the  ultimate  effect  on  information  throughput.  A 
rate  of  100  characters  per  second  is  shown  to  be  possible  with  the  emulated  IBM  2780 
link  over  a normal  telephone  line.  Partly  as  a result  of  this  analysis,  a Mohawk  2400 
programmable  data  terminal  was  procured  by  NTS. 

2.10.3  Network  Testing 

The  problem  of  testing  and  evaluating  the  various  portions  of  the  PARR  network 
was  analyzed  by  ARINC  Research  under  Task  10c,  and  a means  of  terminal  and 
modem  evaluation  was  developed  for  use  at  NTS  and  remote  sites.  A technique  was 
also  developed  to  test  dialed  connections  in  a general  manner  from  the  terminal 
through  the  communications  to  the  computer.  These  techniques  provide  error  detec- 
tion and  the  possibility  of  recovery  in  a minimum  of  elapsed  time,  and  are  now  in 
regular  use  between  terminals  and  the  central  computer.  Results  of  the  study  are 
documented  in  ARINC  Research  publication  W4-1612-TN01,  dated  July  1974. 

2.10.4  CRT  Survey 

Under  Task  lOd,  \RINC  Research  surveyed  the  market  for  small  video-display 
remote  terminals  to  ensure  that  the  most  efficient  and  economical  systems  are  con- 
sidered for  PARR  system  use.  A survey  was  made  of  90  models  from  62  manufac- 
turers, and  the  results  were  informally  reported  to  NTS  in  July  1974. 

The  survey  revealed  that  most  available  models  are  either  too  simple  (glass 
teletype)  or  too  complex  (programmable  intelligent  units)  for  PARR  use.  Some  36  of 
the  90  units  fell  within  these  extremes,  and  generally  met  the  technical  requirements 
as  given  in  Table  1 of  Appendix  A -2.  The  list  was  further  reduced  to  15  by  purchase- 
cost  constraints.  Manufacturers  of  these  15  models  were  contacted  by  telephone  to 
establish  the  availability  of  the  equipment  with  magnetic  tape  cassette  capability, 
hard  copy  printer,  and  through  a General  Services  Administration  contract.  Justifi- 
cation for  the  initial  selection  of  the  Hazeltine  terminal  was  determined  at  the  time 
of  the  survey;  however,  reevaluation  should  be  made  periodically  because  of  the 
extreme  flexibility  and  variability  of  this  market. 
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2.10.9  IMA  Site  Surveys 


ARINC  Research  intended,  under  Task  lOi,  to  survey  each  IMA  site  to  coordinate 
procedures  for  telephone,  terminal  and  modem  installation,  testing,  and  maintenance. 
In  general,  installation  of  the  initial  units  went  smoothly  enough  that  site  surveys  were 
not  needed.  The  three  exceptions  were  at  Cape  Canaveral  (Complex  30),  at  NAD/Oahu, 
and  at  NSSF  San  Diego. 

The  Cape  Canaveral  site  was  visited  two  times  and  all  aspects  of  operation  and 
maintenance  were  thoroughly  investigated.  Error  rate  tests  over  the  2700-mile  link 
were  very  encouraging;  an  error  rate  less  than  0.00001  (one  bit  error  in  100,000 
information  bits)  was  observed. 

A problem  relating  to  procurement  source  delayed  the  installation  of  the  termi- 
nal at  NAD/Oahu.  An  ARINC  Research  representative  performed  the  initial  installa- 
tion and  checked  out  the  terminal  for  operation.  An  error  rate  test  over  that  link 
indicated  considerably  better  service  than  had  been  anticipated,  giving  approximately 
the  same  performance  as  the  link  of  equal  length  with  Florida.  Terminals  at  the 
outer  islands  of  the  Hawaiian  group  can  operate  with  similar  efficacy. 

At  San  Diego  the  Survey,  installation  and  testing  were  uneventful.  Since  the 
terminal  was  sent  by  the  Navy  from  NTS  to  NSSF,  the  manufacturer  does  not  provide 
maintenance  in  San  Diego. 

An  alternative  PARR  terminal  was  evaluated  for  use  in  locations  where  the 
Hazeltine  units  are  not  available:  the  ADM-1  manufactured  by  Lear  Siegler,  Inc.  It 
was  determined  that  all  necessary  functions  of  the  PARR  terminal  could  be  performed 
if  a different  central  computer  translation  table  were  used.  The  table  was  developed 
and  provided  to  NTS  for  incorporation  into  an  ADM  terminal  handler. 

Experience  with  variable  maintenance  quality  and  service  over  the  wide  expanse 
covered  by  the  PARR  network  led  to  the  recommendation  by  ARINC  Research  that  a 
spare  terminal  be  kept  at  NTS/Keyport  and  furnished  as  needed  to  installations 
having  problems. 


2.10.10  Computer  Alternatives 


An  effort  performed  as  Task  lOj  was  that  of  defining  and  evaluating  alternatives 
for  providing  the  PARR  communications  system  with  a dedicated  computer  to  act  as 
the  data  communications  and  file  management  central  site.  The  resulting  report  is 
included  as  Appendix  A-5  herein,  and  is  summarized  below. 


Sequential  steps  in  this  study  were: 


a.  Stating  the  requirements  of  the  PARR  data  system  in  terms  of  the 
functions  that  must  be  performed. 


b.  From  these  functional  requirements,  deriving  a set  of  hardware  and 
software  requirements. 


c.  Describing  the  capabilities  of  the  available  equipments  for  meeting 
these  requirements.  This  determination  was  based  on  published 
information,  solicited  industry  data,  and  interviews. 
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d.  Defining  alternatives  for  the  four  general  eonfiguration  capabilities: 


1)  Communications  concentration 

2)  Preprocessing  of  data 

3)  Provision  of  small  data  system 

4)  Provision  of  complete  data  system 

e.  Determining  alternative  sources  for  procuring  the  various  necessary 

parts  of  the  system. 

A conclusion  favoring  a phased  approach  was  supported  by  both  the  require- 
ments and  the  industry  capabilities  available.  It  appears  possible  to  secure  a data 
communications/file  management  central  system  that  may  be  activated  in  stages,  so 
that  as  each  stage  is  completed  it  may  be  used  while  the  corresponding  capability  in 
the  existing  system  will  serve  as  backup. 

2.10.11  Interface  Unit  Requirements 

Task  10k  under  this  contract  was  the  development  of  requirements  for  a device, 
for  use  with  the  PARR/AUTOVON  communications  network,  that  will  satisfy  the  Joint 
Chiefs  of  Staff  (JCS)  requirement  for  automatic  disconnection  of  terminals  following 
one  minute  of  inactivity  on  the  line.  The  device  will  also  provide  some  capabilities 
for  interface  testing  of  selected  portions  of  the  PARR  communications  network.  The 
specification  was  informally  submitted  to  NTS  by  ARINC  Research,  and  is  included 
as  Appendix  A -6  to  this  report. 

The  JCS  requirement  is  stated  in  JCS  Memorandum  of  l^olicy  No.  151,  and 
generally  reflects  current  operating  procedures  for  facsimile  machines  on  com- 
mercial and  AUTOVON  lines.  In  those  applications  a mechanical  unit  automatically 
answers  an  incoming  call  and  terminates  ("hangs  up  the  telephone")  when  the  call  is 
completed.  Since  those  units  operate  at  aoout  10*^  the  speed  of  the  PARR  terminal,  a 
mechanical  device  is  considered  adequate. 

In  the  PARR  network  a data  modem  supplied  by  the  telephone  company  is  used 
that  will  recognize  a signal  at  the  interface  to  disconnect  or  "hang  up".  Most  modems 
do  not  provide  the  disconnect  function,  and  no  commercial  equipment  is  Itnown  that 
will  satisfy  the  requirement.  For  this  reason  the  requirements  for  a PARR- 
AUTO  VON  Interface  Unit  (PAIU)  were  defined  by  ARINC  Research.  One  unit  was  built 
and  tested  by  NTS  personnel  and  performed  fairly  satisfactorily.  Some  difficulty  was 
experienced  in  completing  calls  prior  to  automatic  hang-up,  and  in  the  mechanical 
construction  of  interconnection.  Since  the  unit  is  to  be  used  in  remote  locations  where 
no  trained  service  personnel  are  available,  and  since  it  is  in  the  experimental  model 
stage  at  this  time,  it  is  recommended  that  the  quality  assurance  provisions  of  the 
specifications  be  strictly  observed. 

2.10.12  Error-Checking  Terminal  Evaluation 

ARINC  Research  evaluated,  under  Task  10j2,  the  feasibility  of  error  checking  at 
the  remote  terminal,  and  its  cost-effectiveness  relative  to  error  checking  at  the 
PARR  central  computer. 

Data  quality  is  a prime  concern  in  any  data  base  operation.  In  the  PARR  system 
the  accuracy  of  the  decisions  of  Torpedo  Mk  48  project  personnel  is  affected  by  the 
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quality  of  the  data  In  the  master  files.  These  data  are  entered  by  operators  at  remote 
terminals  and  are  checked  at  several  steps  in  the  process  for  validity,  both  for  the 
content  of  single  fields  and  for  the  correlation  of  several  fields  of  information.  One 
of  these  steps  is  a process  in  the  central  computer,  executed  when  data  are  Input, 
that  checks  for  several  types  of  errors.  On-line  error  correction  is  time  consuming 
and  makes  inefficient  use  of  the  telephone  lines.  The  study  conducted  under  this  task 
was  intended  to  correct  that  problem  by  moving  error  detection  and  correction  to  an 
off-line  function  at  the  terminal. 

To  evaluate  the  requirements  for  error  checking,  the  current  programs  were 
reviewed.  It  was  noted  that  the  following  types  of  tests  are  performed: 

Times 


Test 

Purpose 

Applied 

Presence 

Ascertains  if  a field  contains  an  entry,  with  no 
regard  to  its  value. 

21 

Justification 

Checks  to  see  if  the  entry  is  present,  and  right-  or 
left- justified  as  required  by  the  input  program 

4 

Numeric 

Determines  if  the  entry  is  an  alpha  or  a numeric 
value  as  required. 

24 

Length 

Checks  the  number  of  characters  in  an  entry. 

12 

Table  Value 

Checks  the  complete  entry  against  a specific  set 
of  allowable  entries  for  that  field. 

19 

In  addition  to  the  basic  single-field  tests  outlined  above,  multiple-field  tests  are 
conducted.  The  following  single-  or  multiple-field  tests  are  performed  in  the  current  1 

system:  j 

Fields  Tests  Number  | 

Tested  per  Field  of  Test 


1 1 24 

1 2 26 

2 1 20 

2 2 4 

3 16 

3 2 0 

Total:  80 


J 

The  scope  of  any  terminal  program  for  checking  errors  should  be  at  least  as  I 

sophisticated  as  that  outlined  above,  with  the  capability  of  growing  to  two  or  more  I 

times  that  level.  I 
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2.10.13  Data  Port  Efficiency  Investigation 


Under  Task  10m,  the  efficiency  of  the  present  data  port  was  evaluated  and 
recommendations  were  made  for  increasing  it.  Two  types  of  data-port  operation  arc 
presently  utilized  in  the  PARR  system: 

a.  Central  office  terminals  connected  to  the  computer  for  long  periods  of 
time  while  update  or  modification  transactions  are  being  entered;  and 

b.  Remote  location  terminals  connected  to  the  computer  for  short  periods 
of  time  for  data  entry  and  retrieval. 

Various  items  of  equipment  are  available  which  allow  the  connection  of  multiple 
terminals  to  one  telephone  line  for  access  to  one  computer  port;  or  more  than  one 
telephone  line  in  call  sequence  order  (in  a manner  similar  to  a telephone  automatic 
call  director)  to  one  or  more  computer  ports. 

Five  approaches  to  increasing  efficiency  were  evaluated,  and  the  recommenda- 
tion was  made  that  a cluster  of  polled  terminals  under  a local  controller  be  the  method 
implemented.  This  approach  would  provide  a substantial  increase  in  efficiency  at  a 
nominal  increase  in  cost  over  the  present  method.  Details  of  the  study  are  given  in 
Appendix  A -7. 

2.10.14  Nixdorf-Honeywell  Link 

Under  Task  lOn,  a study  was  performed  to  determine  the  best  method  of  allow- 
ing the  Nixdorf  model  820  terminal  used  by  Gould  in  the  minor  repair  facilities  to 
access  directly  the  PARR  central  computer.  The  present  method  of  access  is  to  make 
a cassette  recording  on  the  Hazeltine  interface  terminal  for  relay  to  the  PARR  com- 
puter. By  this  method  the  Hazeltine  terminal  operates  in  one  mode  for  communication 
with  the  Nixdorf  terminal  and  in  another  for  transfer  to  the  Honeywell  computer. 

Difficulties  inherent  in  this  procedure  are  that  1)  the  communications  buffers 
are  of  different  lengths:  1000  characters  in  the  Honeywell  computer,  2000  in  the 
Hazeltine  terminal,  and  72  in  the  Nixdorf  terminal;  and  2)  the  Honeywell  computer 
does  not  now  transmit  the  EOT  character  at  the  end  of  each  transmission.  Since  the 
line  length  of  the  Hazeltine  terminal  is  72  characters,  it  can  accept  information  one 
line  at  a time  and  then  transmit  the  collection  of  information  one-half  page  at  a time. 
Also  the  operators  of  the  Hazeltine  terminal  use  the  "local"  button  to  simulate  a 
computer  EOT  transmission. 

There  are  several  possibilities  for  resolving  the  first  difficulty,  i.  e. , by 
shortening  the  transmission  length  of  the  Honeywell  computer.  The  most  feasible  are 
as  follows: 

a.  A Nixdorf  port  could  be  developed  with  a 72-character  buffer.  Programs 
would  then  have  to  present  data  to  COMCOP  one  line  at  a time  instead  of 
one  page  at  a time. 

b.  Using  the  current  1000-character  buffered  ports,  COMCOP  or  an  inter- 
face program  could  receive  data  from  programs  one  page  at  a time  and 
relay  them  one  line  at  a time  to  the  port. 
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With  the  72-character  port,  the  first  of  the  above  alternatives,  more  efficient 
use  is  made  of  available  memory  space  than  by  using,  only  72  of  the  1000  characters 
in  the  Hazeltine  buffer.  On  the  other  hand,  the  port  would  be  infrequently  used. 

When  the  programs  have  to  transmit  data  line-by-line,  their  operation  is  not  as 
efficient  as  when  they  deliver  data  page-by-page,  as  in  the  second  alternative  alx)ve. 

Considering  the  above  alternatives,  the  best  approach  would  be  to  use  an  inter- 
face program  called  by  COMCOP  when  a Nixdorf  model  820  terminal  is  being  serviced. 
This  program  would  operate  between  COMCOP  and  the  requested  program,  passing 
information  in  both  directions  and  serving  as  a special-purpose  Nixdorf  communica- 
tions "cop”.  On  input,  this  "NIXCOP"  would  be  called  by  COMCOP  and  in  turn  call  the 
requested  application  program,  passing  the  necessary  information  and  setting  up  the 
working  storage  for  output.  On  output,  NIXCOP  would  accept  a page  of  information 
from  the  application  program  and  pass  it  line-by-line  to  COMCOP.  It  would  use  only 
a small  amount  of  the  available  communications  buffer  space;  however,  the  relatively 
infrequent  use  of  this  capability  prior  to  the  installation  of  the  front-end  would  justify 
the  inefficiency.  Of  course,  the  expected  line  speed  (about  80  characters  per  second) 
will  be  considerably  below  the  120  characters  per  second  capability  of  the  line  and  the 
capability  of  the  Hazeltine  terminal.  This  situation  may  be  compensated  for  by 
operating  the  Nixdorf  terminal  in  a batch  mode  for  short  transmissions,  using 
requests  from  ^he  cassette  and  not  from  the  keyboard. 

The  second  difficulty,  that  of  the  EOT  deficiency,  could  be  resolved  by  imple- 
mentation of  any  of  three  designs  or  modifications: 

a.  A Nixdorf  port  with  a translation  table  containing  the  EOT  character 

b.  A modification  to  the  communications  controller  to  incorporate  the 
EOT  signal  in  all  operations 

c.  A modification  to  the  Nixdorf  to  provide  line  turn-around  on  the  ETX 
set  as  the  last  character  of  each  Hone3^ell  message. 

For  the  reasons  previously  stated,  a separate  Nixdorf  port  would  not  be  an 
efficient  use  of  resources  at  this  time.  It  would  in  this  case,  however,  be  the  easiest 
solution  to  the  problem. 

Modifying  the  communications  controller  to  send  an  EOT  indication  at  the  end  of 
each  message  would  eliminate  the  convenience  of  the  current  operating  practice  of 
allowing  messages  from  the  computer  or  other  terminals  to  be  displayed  on  the 
bottom  line  of  the  display  screen.  It  would  also  eliminate  multiple  terminal  requests. 
Current  operation  leaves  both  the  computer  and  the  terminal  in  receive  at  all  times 
except  when  transmitting;  the  first  one  in  contention  for  the  line  seizes  it  for  the 
duration  of  its  message.  Only  a short  interval  (200  milliseconds)  exists  when  the 
contention  cannot  be  resolved,  and  in  that  case  the  terminal  retransmits. 

The  recommended  solution  is  a change  in  the  Nixdorf  programming  to  allow 
line  turnaroimd  (thereby  simulating  the  EOT)  on  receipt  of  either  the  ETX  or  EOT, 
instead  of  EOT  only.  Mess  ages  from  the  Hazeltine  will  be  turned  around  on  EOT, 
and  those  from  the  Honeywell  on  ETX.  This  might  be  accomplished  in  one  program 
or  in  two  separate  programs,  with  the  correct  one  loaded  for  each  application. 
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Gould  plans  to  use  a Nixdorf  unit  that  was  moved  in  early  1975  from  Gould's 
Florida  office  to  its  Cleveland  office  for  the  development  of  in-house  configuration 
control  applications,  and  could  include  the  development  of  the  floneywell  computer 
capability. 


2.11  TASK  11:  PARR  PROCEDURES  MANUAL 

Under  Task  11,  ARINC  Research  reviewed  PARR  procedures  for  the  Torpedo 
Mark  48  system.  This  effort  resulted  in  the  development  of  the  PARR  Procedures 
Manual  currently  used  by  NTS/PARR  personnel. 

During  the  performance  of  this  task,  problems  affecting  the  deficiency  data 
collection  and  logistics  accounting  systems  were  also  investigated.  As  a result, 
ARINC  Research  proposed  numerous  recommendations  for  improvement  to  these 
systems. 

The  following  list  of  submittals  reflects  the  scope  of  work  provided  under  this 

task, 

a.  Torpedo  Mk  48  System  Performance  and  Reliability  Reporting  (PARR) 
Procedures  Manual  (Preliminary)  (30  November  1973) 

b.  Torpedo  Mk  48  System  Procedures  Manual,  Comments  and 
Recommendations  (30  November  1973) 

c.  Gould  "Closure  Letters",  Comments  and  Recommendations 
(9  April  1974) 

d.  "Information  Only"  Reports,  Comments  and  Recommendations 
(10  April  1974) 

e.  Utilization  of  "Deficiency  Found  During"  Block  on  PARR  Raw  Data 
Form  (30  May  1974) 

f.  Torpedo  Mk  48  System  Performance  and  Reliability  Reporting 
(PARR)  Procedures  Manual  (3  September  1974) 

g.  Torpedo  Mk  48  System  PARR  Procedures,  Discussion  and 
Recommendations  (3  September  1974) 

h.  Data  Terminal  Operator's  Manual  for  Torpedo  Mk  48  PARR  System 
(Appendix  G of  PARR  Procedures  Manual)  (25  Ocrober  1974) 

i.  PARR  Products  Manual  (Preliminary)  (24  January  1975) 

j.  Screen  Group  Procedures  Manual  for  Torpedo  Mark  48  PARR 
Deficiency  Analysis  Feedback  (DAF)  System  (Appendix  K of  PARR 
Procedures  Manual)  (3  February  1975) 

k.  PARR  Batch  Reports,  Analysis  and  Recommendations  (15  March  1975) 
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2.12  TASK  12:  TORPEDO  MK  48  SUPPORT  I-XJUIPMENT 

DEFICIENCY  DATA  COLLECTION 

Problems  affecting  the  deficiency  data  collection  and  logistics  accounting 
systems  as  related  to  Torpedo  Mk  48  support  equipment  were  investigated  under 
Task  12,  That  study  resulted  in  numerous  recomriendaticns  for  improvement  of  the 
data  systems,  which  were  submitted  to  the  appropiiate  PARR  supervisory  personnel 
as  memorandums. 

In  addition  to  the  areas  covered  in  the  memorandums,  ARINC  Research  par- 
ticipated in  the  preparation  and  development  of  the  following  items  as  they  relate  to 
Torpedo  Mk  48  support  equipment: 

a.  NAVORD  Instruction  4790.  5A,  Torpedo  Mark  48  System  Maintenance 
and  Deficiency  Data  Collection  Procedures  Manual 

b.  NAVORD  form  4790/7,  "PARR  Reliability  and  Maintenance  Report" 

c.  NAVORD  form  8510-48-1/66,  "PARR  Reliability  and  Maintenance 
Report  (Feeder)" 

Finally,  under  this  task,  ARINC  Research  conducted  a study  of  configuration 
and  inventory  accounting  for  the  subject  support  equipment.  Results  of  that  subtask 
are  presented  in  company  publication  W4-1612-TN02. 


2.13  TASK  13:  ADS  DEVELOPMENT  PLAN 

Since  the  PARR  system  makes  use  of  automatic  data  processing  equipment,  a 
requirement  for  an  Automatic  Data  System  (ADS)  plan  was  imposed  in  May  1973  in 
accordance  with  OPNAVINST  5231. 1.  Included  in  the  specifications  for  the  ADS  plan 
were  extensive  requirements  for  communications  planning  and  decision  justification. 
Over  a period  of  several  months  a draft  version  of  an  ADS  plan  was  developed  through 
a cooidinated  effort  of  NTS  and  ARINC  Research  personnel.  The  draft  was  reviewed 
by  NTS  and  forwarded  to  NAVSEA.  The  plan  contained  the  following  elements: 

a.  Probleni/Opportunity  Statement 

b.  Environment  Description 

c.  Objectives 

d.  Assumptions  and  Constraints 

e.  Alternatives 

f.  Costs 

g.  Benefits 

h.  Comparison  of  Alternatives 

i.  Sensitivity  Testing 


2.14  TASK  14:  DEDICATED  ADPE  REQUIR KM KNTS 


Under  Task  14  of  the  contract,  a requirements  study  was  performed  and  a 
specification  prepared  for  the  procurement  of  automatic  data  processing  equipment 
that  would  allow  the  PARR  system  to  decrease  its  dependence  on  NTS/Keyport  ADP 
hardware. 

As  recommended  in  the  computer  alternatives  task  (see  Section  2.10,10),  and 
noted  in  the  task  statement,  the  ADPl’  specification  provides  for  the  following: 

a.  A phased  approach  for  progressing  from  a controlled  front-end 
concentrator  to  a fully  independent  data  system; 

b.  Satisfaction  of  current  operational  requirements  with  a minimum 
of  transitional  problems; 

c.  Growth  of  the  data-file  capability  of  the  PARR  office  so  that 
in-office  storage  and  retrieval  of  an  increasing  amount  of  PARR 
data  may  be  developed; 

d.  The  expectation  that  several  manufacturers  will  be  able  to  meet 
the  specification  requirements  at  all  stages. 

The  specification  was  prepared  in  military  format  and  reflects  the  concept  of 
meeting  all  final  requirements  at  each  of  the  initial  stages  (as  opposed  to  the  phased 
approach).  That  is,  the  intention  is  to  procure  all  equipment  at  once  rather  than  at 
different  times.  Phasing  will  then  be  reserved  for  capability  activation  rather  than 
equipment  installation.  The  advantages  and  disadvantages  of  this  approach  arc 
discussed  in  ARINC  Research  publication  Wr)-lfil2-TN01,  dated  February  1975. 
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2.15  TASK  15:  NUSC  REPORTING  REQUIREMENTS 

ARINC  Research  was  requested,  under  Task  15,  to  define  the  steps  needed  to 
extend  PARR  reporting  capabilities  to  include  specific  requirements  of  the  Naval 
Underwater  Systems  Center  (NUSC),  Newport.  NUSC  had  requested  that  the  PARR 
team  develop  the  capability  to  provide  certain  statistics  on  Mk  48  torpedo  mainte- 
nance and  logistic  events.  Since  only  some  of  the  specific  data  products  requested  by 
NUSC  were  readily  retrievable  from  the  PARR  system,  it  became  necessary  to 
analyze  the  remaining  products  and  the  PARR  data-collection  processes  to  establish  a 
method  for  extracting  the  additional  desired  products.  ARINC  Research  was  requested 
to  perform  the  analysis  to  determine  means  of  retrieving  the  requested  data. 


It  was  concluded  from  the  investigation  that  the  desired  statistics  could  be  pro- 
duced with  relatively  minor  modifications  to  the  existing  PARR  system.  ARINC 
Research  developed  the  specifications  for  the  necessary  PARR  modifications  and  data 
processing.  These  represent  an  expansion  of  existing  PARR  capability  and  should 
improve  the  responsiveness  of  the  system  to  future  requests  as  well  as  the  current 
NUSC  request. 
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The  recommended  modifications  to  the  PARR  system,  together  with  appropriate 
background  information,  are  summarized  below. 

a.  A composite  report  structure  was  developed  through  extensive 
coordination  with  representatives  from  NUSC  and  PARR.  It  is 
recommended  that  this  structure  be  used  for  reporting  the 
requested  maintenance  statistics. 

b.  The  capability  to  access,  via  remote  terminal,  the  source  data 
used  in  developing  reported  maintenance  statistics  was  also 
requested  by  NUSC.  The  Backup  Report  structure  developed  in 
this  effort  would  provide  this  capability  when  used  in  conjunction 
with  existing  PARR  communications  programs. 

c.  The  primary  obstacle  to  producing  these  products  under  the 
current  PARR  system  is  the  absence  of  an  effective  method  for 
coding  and  automatically  categorizing  maintenance  events.  An 
extended  action-coding  scheme  was  designed  during  this 
investigation. 

d.  Improved  flexibility  and  reporting  accuracy  would  be  achieved  by 
modifying  the  editing  and  storage  procedures  for  document  control 
numbers,  reference  designators,  and  drawing  numbers.  In  addi- 
tion, a single  site-coding  scheme  should  be  selected  and  used 
consistently  to  identify  maintenance  locations. 

e.  To  collect  and  store  the  new  data  elements  required,  an  imple- 
mentation approach  is  recommended  that  includes  modifying  the 
structure  and  concept  of  F-cards  in  the  PARR  Master  File  to 
permit  the  storage  of  more  detailed  maintenance-event  data  on  each 
component.  To  collect  the  more  detailed  data,  modifications  to  the 
PARR  report  format  and  the  in-house  review  process  are 
recommendea. 

f.  Upon  implementation  of  the  recommended  PARR  system  modifications, 
the  logic  developed  in  this  investigation  should  be  used  as  the  specifi- 
cations for  computer-programming  activities  related  to  the  NUSC 
products. 

The  modifications  recommended  above,  as  well  as  an  overall  description  of  the 
results  of  Task  15,  appear  in  the  formal  ARINC  Research  report  submitted  to  NTS  at 
the  end  of  the  task.  That  report  is  entitled.  Systems  Analysis,  Mk  48  PARR  Depot 
Reporting  Procedures  (publication  1612-15-4-1332,  Ocicber  1974). 
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1.  Informal  submittal,  ARINC  Research  Corporation,  "NTS/NAVORD 

Data  Link",  dated  9 January  1974  A-1-3 

2.  Interoffice  memorandum,  ARINC  Research  Corporation,  J.  Fountain 
(Santa  Ana)  to  H.  Trueblood  (Keyport),  re:  review  of  NAVORD 
DATA-100  terminal  to  communication  with  planned  NTS  MOHAWK 

2400  terminal;  dated  23  April  1974  A-1-5 
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NTS/NAVORD  DATA  LINK 


The  DATA-100  terminal  at  NAVORD  could  be  used  to  provide  a data  link  with 
NTS/Keyport  in  any  of  several  ways,  all  requiring  some  equipment  modification. 
Both  the  current  configurations  and  possible  modifications  will  be  discussed. 


At  NTS/Kevport  the  Honeywell  model  2070  computer  is  used  with  a Honeywell 
model  286  commimications  controller  and  Honeywell  model  285  communication 
adaptors  for  each  of  four  lines.  These  provide  1200  bps  asynchronous  data  links  to 
Hazeltine  remote  terminals.  Two  other  model  285  adaptors  provide  a 2000  bps 
synchronous  data  link  to  other  Honeywell  computers. 


The  DATA  100  Corp.  model  78  programmed  terminal  at  NAVORD  consists  of; 

a.  Controller  - 8 kilobyte  memory 

b.  Card  Reader  - 600  cards/minute 

c.  Line  Printer  - 400  lines/minute,  132  characters/line 

d.  CRT  display  - 24  lines,  80  characters/line 

e.  Two  synchronous  modem  controllers  - 2000,  4800  bps 

Modifying  the  Honey\vell  2070  to  permit  access  by  a conventional  remote-batch 
terminal  would  benefit  a wide  group  of  Navy  users  who  have  the  equipment,  since  the 
modification  would  not  necessarily  be  for  NTS/Keyport  alone  - it  could  be  sponsored 
by  NAVORD  for  all  applications.  The  modification  would  be  somewhat  difficult  in 
that  detailed  knowledge  of  communication  disciplines  and  skill  with  Honeywell 
assembly  language  are  required.  Further,  while  the  Honeywell  controller  software 
is  of  an  efficient  design,  details  of  the  design  are  not  easily  understood. 

Developing  a program  for  the  DATA  100  that  would  emulate  a Honeywell  CPU 
would  have  similar  benefits  as  the  above,  except  that  the  remote  terminal  would  have 
to  be  the  DATA  100.  The  interface  is  in  Honeywell  code  with  a line  control  logic 
similar  to  the  IBM  bisynchronous  communications  method  (BISYNC)  but  considerably 
simpler.  Again,  a development  program  would  be  required  for  some  familiarity 
gained  about  Honeywell  operations.  Software  is  available  for  emulating  the 
IBM  360-20,  IBM  2780,  Univac  1004,  and  CDC  200  UT  in  both  ASCII  and  BCD. 

Thus,  there  is  no  common  set  of  equipment  at  this  time.  Modifications  may  be 
made  to  the  Honeywell,  the  DATA  100,  and/or  the  Hazeltine  2000.  Alternatives  for 
the  data  link  are  therefore  as  follows: 

a.  Modify  a Honeywell  model  2070  to  emulate  the  counterpart  of  available 
DATA  100  terminal  emulators,  starting  with  either  the  Honeyavell 
type  2440  remote  transmission  terminal  (RTT)  or  central  processor- 
to-central  processor  (CP-CP)  controller  module; 
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b.  Modify  the  DATA  100  to  communicate  with  the  Honeywell  CP-CP 
controller  module; 

c.  Modify  the  DATA  100  to  emulate  the  PARR  remote  terminal; 

d.  Modify  the  DATA  100  to  communicate  with  the  Hazeline  remote 
terminal. 

A disadvantage  of  each  approach  is  that  equipment  has  to  be  significantly 
modified. 

Another  development  for  the  DATA  100  with  direct  application  to  PARR,  but  not 
to  other  Honeywell  users,  would  be  to  have  the  DATA  100  exactly  emulate  the  PARR 
remote  terminal  (i.  e. , the  Hazeltine  2000  as  PARR  is  currently  using  it).  The 
advantage  is  that  the  DATA  100  user  could  access  the  Honeywell  2070  directly  through 
available  lines.  It  should  be  noted,  though,  this  usage  was  not  anticipated  in  the 
PARR  System  Plan.  If  the  traffic  becomes  significant,  more  lines  should  be 
installed.  At  the  DATA  100  end,  an  asynchronous  modem  controller  and  202-C 
modem  would  be  required. 

Finally,  the  DATA  100  could  be  made  to  operate  to  the  Hazeltine  with  the  latter 
in  some  mode  other  than  that  used  for  PARR  operation.  Changes,  by  switch  settings 
on  the  Hazeltine,  might  be  in  parity,  line  speed,  or  line  discipline.  This  solution 
could  be  the  least  expensive  but  would  require  a two-stage  retrieval  of  data. 
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ARINC  R!IS;£A:;CH  CORPORATION 

Interofficu  Memorandum 


TO:  H.  Trueblood  DATE:  April  23,  1974 

Keyport  Section 

SUBJECT:  Work  Order  1612-10,  REPLY  TO:  SNA/EI:G-74-33 

Subtask  B W.O.  1612-10 

•REFERENCE:  SNA/74-04,  dated  9 Jan  74  FROM:  J.  Fountain 

Santa  Ana 

A review  of  the  capability  of  the  MAVORD  DATA-lOO  terminal  to  communicate 
with  the  planned  NTS  f^OHAWK  2400  terminal  v/as  requested  under  this  work  order 
task.  The  referenced  memo  contains  the  previous  site  descriptions  and 
recommendations.  The  documentation  on  botli  indicates  that  they  can  em.ulate 
the  IBM  2780  Data  Transmission  Terminal.  This  terminal  is  designed  to 
communicate  with  a variety  of  IBM  equipment  including  another  2780.  Therefore, 

. it  can  be  planned  to  use  this  mode  of  operation  from  NTS  to  NAVORD. 

It  is  important  to  select  the  correct  emulator  because  most  remote  batch 
terminals  such  as  the  CDC  200  LIT  and  the  IBM  350/20  can  communicate  with 
computers  having  the  appropriate  responsive  line  logic.  They  cannot,  in  general, 
talk  to  each  other  since  the  line  logic  is  not  symmetrical . The  computer  will 
poll  and  the  terminal  will  respond  to  that  poll. 

Selecting  the  cmiMator  imposes  the  restrictions  inherent  in  the  terminal 
emulated.  The  IBM  2780  is  designed  as  a card  handling  terminal.  All  data  is 
therefore  blocked  in  80-character  blocks  with  a maximum  of  400  characters  in 
any  one  transmission.  Since  the  2780  operates  hal f~duplexi  at  the  end  of  each 
transmission  the  line  is  turned  around  for  a block  acknowledgement.  Space 
compression  is  available  if  the  transmission  code  is  EBCDIC  thereby  increasing 
the  throughput.  This  is  not  available  in  USASCII  code  operation.  A tape 
prepared  on  the  Honeyv/ell  mus’t  therefore  be  prepared  as  EBCDIC  card  images  to 
be  transmitted  m.ost  efficiently. 

In  order  to  estimate  the  actual  throughput,  an  effective  line  speed  must 
be  calculated  taking  into  account  the  propagation  time  for  each  message  over 
the  3000  miles  between  Keyport  and  Washington,  the  expected  error  rate  over  the 
line  to  be  used,  and  the  size  of  the  transmitted  block  which  must  be  retransmitted 
if  an  error  occurs.  Considering  a dial-up  WATS  line,  the  modem  rate  v;ould  2000 
bits  per  second.  At  an  error  rate  of  1 bit  in  10,000,  the  effective  line  speed 
with  the  optimum  block  size  of  200  characters  is  1432  bits  per  second  with  full 
duplex  operation.  Bringing  in  propagation  and  acknowledgement  protocol,  the 
effective  line  speed  drops  to  800  bits  or  100  characters  per  second. 
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H,  Trueblood  -2-  April  23,  1974 

W,0.  1612-10  SNA/ENG-74-33 


The  implication  of  the  above  calculation  is  best  seen  as  determining 
the  time  required  to  send  a tape  from  NTS  to  NAVORD.  If  the  tape  contained 
400-500  pages,  the  approximate  number  of  characters  would  be  3 million.  At 
the  theoretical  maximum  effective  line  speed  of  2000  bits-per-second  (250 
characters-per-second)  the  tape  would  go  in  just  over  2 hours.  However,  at 
the  realistic  rate  of  800  bits-per-second  (100  characters-per-second)  the  tape 
v/ould  take  over  8 hours  to  transmit.  The  communications  costs  could  become 
significant  if  the  number  of  tapes  to  be  exchanged  were  large. 

In  summary,  the  NTS  and  NAVORD  terminal  can  communicate  with  each  other 
exchanging  information  as  if  they  v.ere  IBM  2780s.  The  only  problem  associated 
with  this  operation  is  the  time  it  will  take  to  transmit  a large  amount  of 
information  from  one  place  to  the  other.  Possible  improvements  include  a 
dedicated,  data-condi tioned  4-wire  line  or  more  sophisticated  modems  and 
software  for  higher  speeds. 
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SURVEY  OF  CRT  DISPLAY  MODELS 


To  determine  the  most  cost-effective  CRT  display  unit  for  PARR  remote 
terminal  applications,  ARINC  Research  surveyed  90  CRT  units  of  02  manufacturers. 
Table  1 lists  the  criteria  for  an  acceptable  CRT  display  model.  Most  models  sur- 
veyed were  either  too  simple  (Rlass  teletype)  or  too  complex  (programmable 
intelligent  units)  for  PARR  use.  Of  the  90  units  surveyed,  35  were  selected  as  meet- 
ing most  technical  requirements.  Table  2 identifies  the  candidates  and  notes  any 
desirable  features  that  might  be  lacking. 

The  35  candidates  meeting  the  technical  requirements  were  reduced  to  16  by 
application  of  the  applicable  price  constraint  (requirement  13,  Table  1).  Manufac- 
turers of  this  group  were  contacted  by  telephone  to  determine  the  availability  of 
magnetic  tape  cassette  (MTC),  hard  copy  printer  (HCP),  and  General  Services 
Administration  contract.  The  survey  has  been  updated  several  times  in  the  past  year; 
latest  results  are  given  in  Table  3. 

The  selection  requirements  given  in  Table  1 were  developed  around  current 
experience  with  existing  terminals,  and  are  commented  on  below.  The  numbers  pre- 
ceding the  comments  correspond  to  those  in  the  first  column  of  Table  1. 

Item  of 

Table  1 Comment 

1 A nominal  2000-character  display  has  been  found  essential  for 
most  PARR  data  forms.  A great  deal  of  information  may  be  on 
a PARR  form;  having  the  entire  form  available  for  display  in  a 
structure  similar  to  that  on  paper  promotes  faster  operator 
training. 

2 While  there  is  no  need  for  lower-case  character  display,  the 
terminal  should  display  upper  case  letters  (26),  numerals  (10), 
and  a reasonable  number  of  special  characters  (28),  yielding  a 
total  of  64  display  characters. 

3 A method  must  be  available  to  indicate  fixed  and  variable  data 
in  a form  fill-in  application  without  blinking,  i.  e. , variable 
intensity. 

4 The  current  system  operates  at  1200  bps  with  even  parity, 
asynchronously  with  keyboard  control  of  "Request  To  Send”. 

5 Remote  positioning  of  the  display  cursor  will  allow  special 
report  formatting  for  low-error  visual  interpretation. 

6 Efficient  use  of  communication  lines  require  continuous  block 
or  message  formatted  data.  The  current  block  size  is 

1000  characters. 

7 Off-line  editing  is  required  to  provide  easy  correction  of  invalid 
data,  compensating  for  the  loss  of  keypunch  verification  on 
data  input. 
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Table  1 

Item  Comment 


8 Fixed-form  data  should  be  protected  from  accidental  erasure  by 
the  operator. 

9 To  minimize  block  size,  only  variable  data  should  be  transmitted. 

10  Full  control  and  operation  of  tape  and  printer  peripherals  must 
be  available  off-line  for  data  capture  without  using  communica- 
tions or  computer  time. 

11  Peripherals  must  be  included  in  the  supplied  and  maintained 
terminal  set.  The  storage  medium  must  have  two  accessible 
locations,  e.  g. , a dual  cassette  tape,  for  multiple  forms  and 
data. 

12  Since  NTS  is  the  purchaser,  a valid  GSA  contract  must  be  in 
force,  with  a desirable  feature  being  that  all  equipment  be  avail- 
able on  lease. 

13  For  purposes  of  establishing  a dividing  line  between  "more"  and 
"less"  intelligent  terminals,  an  arbitrary  purchase  price  limit 
of  $4000  is  set  for  CRT. 

14  Adequate  equipment  is  available  for  a lease  period  at  less  than 
$350  per  month. 

TABLE  1.  CRT  DISPLAY  REQUIREMENTS 

1.  2000  character  display  (minimum  = 72  x 24  = 1728) 

2.  96  ASCII  character  set,  64  displayed 

3.  Variable  intensity,  background/foreground 

4.  1200  bps  asynchronous  controllable  parity 

5.  Cursor  positioning 

6.  Page  or  block  mode  with  1000  character  minimum 

7.  Editing  of  character  and  line 

8.  Protected  (unerasable)  form-data 

9.  Transmit  data  only  for  short  messages 

10.  Off-line  data  input,  editing,  and  peripheral  control 

11.  Dual-drive  tape  and  printer  peripherals 

12.  GSA  contract  available 

13.  CRT  purchase  less  than  $4000 

14.  Total  GSA  lease  for  less  than  $350  per  month 
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TABLE  2.  CANDIDATE  PARR  TERMINALS  (Sheet  2 of  2) 


TABLE  3.  FINAL  SELECTION  OF  PARR  TERMINAL 


Company 

MTC 

HCP 

GSA 

Notes 

Hazeltlne 

Yes 

Yes 

Yes 

Ann  Arbor  Terminals 

No 

No 

No 

Applied  Digital  Data  Systems 

No 

Yes 

Yes 

Cassette  interface  and 
floppy  disc  interface 

Automatic  Electronics 

No 

No 

No 

OEM  supplier 

Beehive  Medical 

No 

No 

No 

Conrac 

No 

No 

No 

OEM  supplier 

Data  media 

No 

No 

Yes 

Printer  buffer 

Delta  Data 

Yes 

Yes 

Yes 

No  GSA  lease 

ICC-Milgo 

No 

No 

No 

Printer  interface 

Jacquard 

No 

No 

No 

Disc  and  printer 
interfaces 

Lear  Siegler 

No 

No 

Yes 

GSA  purchase  only, 
printer  interface 

Omron  R&D 

No 

No 

No 

GSA  bid  in,  cassette 
and  printer  interfaces 

Tektronix 

Yes 

Yes 

Yes 

Both  floppy  disc  and 
cassette 

Teletype 

No 

Yes 

Y es 

Teletype 

Westinghouse 


Yes 


Yes 


No 


GSA  purchase 
only,  2%  discount 


appp:ndix  a -3 

EVALUATION  OF  SMART  FRONT-END 


As  Phase  2 of  PARR  system  development,*  a "smart"  interface  between  the 
existing  data  processing  computer  and  the  communication  lines  for  the  PARR  system 
is  being  considered.  This  appendix  reviews  the  capability  and  cost-effectiveness  of 
that  technique  for  releasing  data  processing  computer  core  for  batch  work;  and  evalu- 
ates, from  the  terminal  user's  viewpoint,  sj'stem  operation  w'ith  the  new'  front-end. 


1.  CURRENT  OPERATIONS 

Communications  control  is  now'  a function  of  the  data  processing  computer. 
Program  softw'are  includes  a communications  policeman  and  communications  control- 
ler. Computer  hardware  includes  core  storage,  multichannel  communications 
control  (1  per  64  lines),  communications  line  adaptors  (1  per  line),  and  movable-head 
disk  storage. 

Data  are  input  from  a remote  terminal  over  dialed  telephone  lines  to  the  line 
adaptor,  then  to  the  multichannel  control  for  buffer  storage.  The  communications 
controller  manages  the  transfer  to  temporary  disk  storage  and  then  on  to  the  com- 
munications policeman  for  transfer  to  a requesting  program.  Output  data  follow  the 
reverse  path:  program,  policeman,  controller,  disk,  data  buffer,  multichannel  con- 
trol, line  adaptor,  telephone  line,  and  remote  terminal.  The  disk  storage  allows 
multiple  input/output  messages  during  program  delays.  The  approximate  amount  of 
storage  now  used  is; 

a.  Policeman  — 5,000  words  of  core 

b.  Controller  — 20,000  w'ords  of  core 

c.  Multichannel  control  — 2,000  w'ords  of  core 

d.  Disk  — 20  cylinders,  500,000  characters 


2.  FRONT-END  OPERATIONS 

Under  the  "smart"  interface  concept,  all  control  of  communications  is  moved  to 
a dedicated  communications  processor  (e.g. , the  DATANET  2000)  for  front-end 
operations.  This  frees  the  data  processing  computer  from  that  task,  although  it  must 
still  handle  communications  between  requesting  programs  and  the  front-end.  Front- 
end  software  would  include  a data  processor,  consisting  of  a communications  police- 
man (one  in  each  partition)  and  a communications  interface  module;  and  a communi- 
cations processor  or  controller.  The  hardware  includes: 

a.  Data  Processor 

— Interface  module  hardware 
— System  buffer  core  storage 


♦See  PARR  System  Plan.  ARINC  Research  Publication  1612-01-1-1240,  p.  3-1 
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b.  Communications  Processor 


— Processor  CPU 

— Basic  multiline  controller  (2  for  24  lines) 

— Tune  interface  modules  (1  for  each  line) 

— Fixed-head  disk  storage 
— Control  console 

Data  are  input  from  a remote  terminal  over  dialed  telephone  lines  to  the  line 
interface  module,  then  to  the  multiline  controller  for  placement  in  buffer  core 
storage.  The  communications  controller  software  manages  to  transfer  to  temporary 
disk  storage,  and  then  to  the  coupler  buffer  when  requested  by  the  data  processor. 

The  data  are  then  routed  through  a high-speed  channel  from  coupler  buffer  to  system 
buffer  in  the  data  processor,  and  on  to  a policeman  for  transfer  to  a requestiiig  pro- 
gram. Output  data  follow  the  reverse  path  from  program  to  remote  terminal.  As 
in  the  present  system  the  disk  is  used  to  compensate  for  program  delays,  but  here  it 
is  also  used  for  commimications  processor  recovery  from  failure.  Recovery  records 
and  tables  are  maintained  on  the  disk.  The  approximate  amount  of  storage  which 
might  be  used  in  the  front-end  is: 

a.  Policeman  - 2,000  words  of  data  processor  core 

b.  Interface  module  — 4,000  words  of  data  processor  core  each 

c.  Communications  controller  - 40,000  words  of  communications- 
processor  core 

d.  Disk  - 500,  000  characters 


3.  COMPARISON  OF  ALTERNATIVES 

It  can  be  seen  from  the  above  operating  summaries  that  the  functioning  of  the 
two  front-end  alternatives  is  quite  similar.  The  manufacturer  (DATANET)  has  gone 
to  great  effort  to  accomplish  this  similarity  to  make  the  transition  to  a "smart"  front- 
end  a smooth  one.  Assuming  two  partitions,  one  for  communication  and  the  other 
processing  batch  work,  the  core  storage  requirements  in  the  data  processor  is 
reduced  from  25,000  to  8,000  w'ords  of  core.  The  17,000  word  reduction  is  accom- 
plished by  adding  40,000  words  of  communications  processor  core.  This  is  quite 
efficient,  considering  the  overhead  fimctions  required. 

Possibly  more  important  than  the  core  savings  is  the  reduction  in  the  number  of 
interrupts  to  data  processor  operations.  When  the  data  processor  handles  communi- 
cation control,  those  interrupts  occur  frequently  — as  often  as  once  per  character. 
With  front-end  operation,  the  character  interrupts  are  in  the  communications 
processor.  Only  one  interrupt  is  required  in  the  data  processor  for  each  message  or 
message  segment  (from  1 to  4,000  characters). 

The  performance  impact  of  a reduction  in  interrupt  frequency  is  difficult  to 
assess  because  the  reduction  is  only  effective  during  actual  data  transfer.  With  a 
large  communications  traffic  load,  however,  the  impact  would  be  significant.  This 
impact  could  be  evaluated  by  benchmark  testing  with  and  without  communications 
functioning. 
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"Transparency"  is  a major  attribute  of  both  alternatives.  In  each,  the  terminal 
user  is  aware  only  of  sending  messaives  to  and  receiving  messages  from  an  active 
program.  The  advantage  of  this  transparency  is  the  apparent  simplicity  of  the  data 
transfer  process.  The  disadvantage  is  that  no  isolation  is  provided  between  the  user 
and  data  processor  problems. 

In  the  PARR  S>’stem  Plan  discussion  of  Phase  2 operation  with  a front-end,  it 
was  pointed  out  that  the  front-end  should  provide  several  features,  including  error 
checking  and  address  processing.  These  features  would  enable  the  communications 
processor  to  perform  some  tasks  without  bothering  the  data  processor  (like  a good 
secretary).  They  also  allow  the  network  to  continue  functioning  at  a reduced  level  of 
effectiveness  when  the  data  processor  is  down.  It  is  conceiv'able  that  the  DATANET 
2000  could  be  programmed  to  accomplish  this  backup  operation;  however,  no  such 
provision  has  been  made. 

Operational  flexibility  is  significantly  greater  with  the  front-end  alternative, 
since  terminals  with  special  characteristics  may  be  specified  and  translation  tables 
may  be  modified  under  standard  provisions  rather  than  requiring  custom  program- 
ming as  is  now  the  case. 
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APPENDIX  A -4 

SPECIFICATION  FOR  PARR  REMOTE  TERMINAL  SET 
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1.0  SCOPE 

This  specification  describes  the  functional  and  electrical  characteristics  of 
the  PARR  Remote  Terminal  Set.  The  set  provides  complete  data  acquisi- 
tion, formatting,  storage,  retrieval,  display,  and  communication  facilities; 
and  may  be  used  in  certain  NAVORD  data  collection  and  reporting  programs 
where  independent  terminal  operations  are  necessary. 


2.0  APPLICABLE  DOCUMENTS 

a.  ELA  Standard  RS-232C,  Interface  Between  Data  Processing  Equipment 
and  Data  Communication  Equipment,  August  1969 

b.  ARINC  Research  Corporation,  PARR  System  Plan,  publication 
1612-01-1-1240,  July  1974 


3.0  REQUIREMENTS 

3.1  GENERAL 

The  PARR  Remote  Terminal  Set  shall  be  a stand-alone,  alphanumeric  CRT 
unit  with  magnetic  tape  cassette,  printer,  and  modem.  This  set  shall  have 
the  overall  capability  of  displaying  1900  alphanumeric  characters  to  store, 
retrieve,  and  print  data;  to  provide  local  and  command  editing;  and  to  trans- 
mit and  receive  digital  information  at  speeds  up  to  1200  bps. 

3.2  DISPLAY  UNIT 

3.2.1  Display  Characteristics 

Display-unit  characteristics  of  the  Remote  Terminal  Set  shall  be  as  follows: 

a.  Minimum  character  capacity:  24  lines  of  characters,  74  characters 

per  line;  screen  capacity:  1900 
characters 

b.  CRT  display:  12-inch  diagonal  CRT;  standard  raster; 

525  lines,  30  frames/sec. ; optional 
raster:  625  lines,  25  frames/sec. 

c.  Character  style:  5x7  dot  matrix  pattern 

d.  Character  repertoire:  64  TTSACII  alphanumeric  characters  plus 

one  special  symbol 

e.  Character  size:  Nominal  character  height;  0. 119  inch 

(6 -inch  raster  height) 
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f.  Split  screen: 


Two  video  intensities  shall  be  available 
(full  intensity  in  foreground,  low  inten- 
sity in  background)  and  controllable  by 
the  remote  CPU. 


3. 2. 2 Communication  Interface 


a.  Data  transmission  rate:  Standard  (1200  bps) 

b.  Data  interface:  Shall  be  EIA  RS232-C  with  Bell  202C 

type  data  set  compatibility.  A front- 
panel  toggle  switch  shall  permit  chan- 
nel turnaround  on  EOT  code  in  normal 
PARR  operational  mode. 

3.2.3  Functional  Description 
3.2. 3.1  Operating  Modes 

The  display  unit  shall  be  capable  of  operating  in  one  of  three  modes:  batch, 
half  duplex,  and  full  duplex.  The  normal  PARR  mode  is  batch,  in  which 
data  are  entered  from  the  keyboard  or  from  the  tape  cassette  unit  onto  the 
display  screen.  Editing  controls  allow  the  following  functions  from  key- 
board and  CPU: 


a.  Insert  line 

b.  Delete  line 

c.  Insert  character* 

d.  Delete  character* 

e.  Clear  screen 

f.  Clear  foreground 

g.  Cursor  controls* 


h.  Home  cursor 

i.  Address  cursor** 

j.  Print 

k.  Transmit 

l.  Set  foreground 

m.  Set  background 


3. 2. 3. 2 Data  Transmission 


Data  shall  be  transmittable  to  one  of  the  following  units: 


a.  Modem  for  communication 

b.  Tape  cassette  unit  for  storage 

c.  Printer  for  hard  copy. 


♦Not  available  for  CPU 
♦♦Available  only  for  CPU 
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3.2.4 


Keyboard 

The  keyboard  shall  contain  three  keyboard  groups:  teletype,  a 10-key 
adding  machine,  and  13-key  editing  and  cursor  control.  The  keyboard 
enclosure  shall  contain  the  following  elements: 

a.  Indicators 

(1)  Transmit 

(2)  Print 

b.  Pushbuttons 


(1)  Power  on/off 

(2)  Break 

(3)  System  reset 

c.  Indicator/pushbutton  combinations 

(1)  Receive  mode  indicator/set  to  receive  and  local  mode 

(2)  Local  mode  indicator/set  to  local  mode  only 

(3)  Parity  error  indicator/reset  parity  error  indicator 

The  keyboard  shall  contain  no  mechanical  contacts  and  shall  be  removable. 
An  additional  power  on/off  switch  shall  be  on  the  front  panel  of  the  display 
for  power  turnon  when  keyboard  is  removed. 

3.2.5  Display  Installation 

Display  installation  requirements  shall  be  as  follows. 

3.2.5. 1 Power  Requirements 

a.  Primary  Power  — Line  cord  shall  be  7 feet  long,  3 wire,  fixed  to 
terminal;  300  volt-amperes  maximum;  115/230  Vac,  50/60  Hz,  nom- 
inal input.  Power  settings: 

(1)  Low:  90/180-110/220  Vac 

(2)  Med:  104/208-126/250  Vac 

(3)  High:  114/224-136/272  Vac 

b.  Circuit  Protection  — Dc  power  supply  shall  shut  down  automatically  for 
overvoltage,  short  circuit,  or  overtemperature  condition.  Power  sup- 
ply shall  be  resettable  by  turning  primary  power  off  for  5 seconds. 

3. 2. 5. 2 Environmental  Requirements 

a.  Temperature:  10°  to  40°  C 

b.  Humidity:  OO'jf  relative  humidity,  noncondensing 
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3.2.5. 3 Physical  Characteristics  (Nominal) 

a.  Dimensions  (with  keyboard): 

(1)  Height:  12. 5 inches  (31.  8 cm) 

(2)  Depth:  22. 0 inches  (55.  9 cm) 

(3)  Width:  18. 5 inches  (47.  0 cm) 

b.  Depth  with  keyboard  removed:  16  inches  (40.6  cm) 

c.  Dimensions  (keyboard  only): 

(1)  Height:  2.8  inches  (7.1  cm) 

(2)  Depth:  6.1  inches  (15.6  cm) 

(3)  Width:  18. 5 inches  (47.  0 cm) 

d.  Weight  v/itb  keyboard;  62  pounds  (28. 2 kg) 

e.  Electrical  cable/connector  interfaces 

(1)  Keyboard  to  display  — 5-foot  (1.52  meter)  cable  from  keyboard, 
terminated  with  54-pin  HDR-series  connector.  Mating  connector 
on  display  rear  panel. 

(2)  Display  to  data  set  — 10-foot  (3.05  meter)  cable  from  display 
termin  with  DB25-P  connector. 

3.3  MAGNETIC  TAPE  CASSETTE 

3.3.1  General 


The  magnetic  tape  cassette  unit  shall  consist  of  two  independent  tape  trans- 
ports capable  of  record  and  playback  digital  data.  The  transport  shall 
mechanically  accept  standard  (Phillips)  tape  cassettes.  Operation  shall  be 
initiated  through  either  remote  CPU  command  or  operator  action.  The 
operator  shall  be  able  to  control  tape  operation  through  the  keyboard  con- 
trols located  on  the  cassette  console.  The  console  shall  consist  of 
13  lighted  pushbuttons,  four  indicator  lights,  and  two  tape-engaging  levers. 

3.3.2  Functional  Description 

The  tape  cassette  shall  perform  three  functions: 

a.  Keyboard  entry 

b.  I/O  receive/record 

c.  Data  playback/transmit 

Each  of  these  functions  shall  have  two  modes  of  operation;  continuous  and 
block. 
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3. 3. 2.1  Data  Playback/Transmit-Block  Page-Off  Line 

The  operator  shall  initiate  playback  via  a tape  cassette  console.  A single 
block  of  data  shall  be  played  back  to  the  display.  Playback  shall  be  termi- 
nated at  the  end  of  each  block. 


3. 3. 2.2  Keyboard  Entry-Block  Mode-Off  Line 

Tape  recording  shall  be  initiated  by  depressing  a command  ("SHIFT  PRINT") 
at  the  keyboard.  The  transfer  rate  of  data  from  the  terminal  to  the  tape 
cassette  shall  be  2400  baud,  with  the  keyboard  inhibited  during  transfer. 

(This  mode  allows  a block  to  include  up  to  1,997  characters.) 

3. 3. 2.3  Data  Playback/Transmit-Block  Page-On  Line 

The  playback  mode  shall  be  initiated  via  the  tape  cassette  console  upon 
receipt  of  an  "X  ON"  command.  A block  of  data  shall  be  played  back  and 
displayed,  and  when  playback  is  complete  the  block  shall  automatically 
transmit  to  the  CPU.  A "RESET"  command  shall  clear  playback. 

3. 3.  2. 4 I/O  Receive/Record-Block  Mode-On  Line 

Data  shall  be  loaded  into  the  terminal  buffer  and  tape  cassette  buffer 
simultaneously  at  the  baud  rate  selected  by  the  terminal. 

3.3.2. 5 Keyboard  Entry-Continuous  Mode- Off  Line 

A carriage  return  (CR)  typed  on  the  keyboard  shall  initiate  "RECORD  TAPE", 
and  transfer  the  data  from  the  terminal  to  the  tape  cassette.  Transfer  shall 
be  at  2400  baud,  and  during  the  transfer  keyboard  functions  shall  be  inhibited. 
(In  this  mode  of  operation  the  display  will  roll  up  under  keyboard  entry. ) 

3. 3. 2.6  Data  Playback/Transmit-Continuous  Page-On  Line 

The  operator  shall  initiate  playback  via  the  tape  cassette  console.  The  tape 
cassette  shall  play  back  a block  of  data  to  be  displayed,  and  the  block  shall 
be  automatically  transmitted  to  the  CPU.  At  the  end  of  data  transmission 
the  tape  cassette  shall  play  back  the  next  block  and  the  cycle  will  be 
repeated.  Playback  shall  be  terminated  at  the  end  of  the  file.  The  display 
shall  clear  at  the  beginning  of  each  block. 

3.3.3  Software  Control 


When  the  tape  cassette  system  is  on  line,  the  CPU  shall  be  able  to  transmit 
codes  to  simulate  the  following  operator  actions: 


Control  Shifted  Period 


Action 

Followed  by; 

a. 

Playback  1 

@ 

b. 

Playback  2 

P 

c. 

Record  1 

0 
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Control  Shifted  Period 


Action 

Followed  by; 

d. 

Record  2 

0 

e. 

Rewind  1 

f. 

Rewind  2 

0 

g* 

Reset 

SPACE 

A delayed  X-ON  option  shall  be  incorporated  into  the  tape  cassette  to  make 
the  following  sequence  possible  at  1200  bps; 

a.  Reset,  rewind,  playback 

b.  X-ON  EOT 


3.3.4 


The  second  command  shall  cause  1)  control  to  shift  to  the  terminal,  and 
2)  the  transfer  of  one  record  from  the  cassette  to  the  screen,  with  subse- 
quent transmittal.  Control  shall  then  be  returned  to  the  computer. 

(NOTE:  As  a consequence  of  the  above  option,  the  capability  of  the  termi- 
nal to  respond  to  the  remote  transmit  command  is  eliminated.) 


Tape  Cassette  Console  Controls 
Tape  cassette  console  controls  shall  be  as  follows: 
a.  Playback  1; 


b.  Playback  2: 

c.  Record  1: 

d.  Record  2: 

e.  Rewind  1: 

f.  Rewind  2: 

g.  Reset: 

h.  Interlock: 


Initiates  playback  of  cassette  #1  except  in  block 
on-line  mode,  where  it  conditions  cassette  for 
response  to  "X  ON”. 

Controls  cassette  #2  as  described  above. 

Enables  recordings  to  be  made  on  cassette  #1. 

Enables  recordings  to  be  made  on  cassette  #2. 

Causes  cassette  #1  to  rewind  to  clear  leader. 

Causes  cassette  #2  to  rewind  to  clear  leader. 

Clears  all  modes  of  operation  and  generates  an 
inner-file  gap  if  in  the  record  mode. 

Must  be  depressed  simultaneously  with  record  to 
prevent  accidental  recordings. 


i.  Block/continuous : Determines  mode  of  operation. 


j.  On  line: 

k.  Duplicate: 


Enables  CPU  operation  and  automatic  transmit. 

Enables  duplicating  from  one  cassette  to  the  other. 
Duplication  shall  terminate  at  the  end  of  each  block 
if  the  system  is  in  the  block  mode,  and  at  the  end 
of  a file  if  the  system  is  in  the  continuous  mode. 
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Page/ character; 


"Page"  will  route  the  data  to  the  Hazeltine  2000 
for  display.  "Character"  will  transmit  directly 
to  the  CPU  at  the  baud  rate  selected  by  the 
Hazeltine  2000. 


m.  Power  on 


3. 3. 4.1  Electrical 

Input/output  data  rate;  2400  baud,  or  any  baud  rate  selected  by  the  dis- 
play. All  inputs  and  outputs  shall  be  TTL 
(transistor-transistor  logic)  compatible. 

Recording  format-  Phase  encoded  single  track  — read/write  head, 

0. 056-inch  track  width. 


Recording  density; 
Forward  speed; 
Start/ stop  time; 
Rewind  time; 


400  bpi/800  bpi 

6 ips  ± 2%  long-term  stability;  servo  controlled 
40  milliseconds  each 

90  seconds,  maximum;  head  retracted  (typically 
50  seconds) 


Inter-record  gap;  100  milliseconds 


Inter-file  gap; 
EOT/BOT; 


File  protect; 


1 second 

Optical  sense  clear  leader;  indicator  on  console 
displays  status 

Switch  closure  senses  absence  of  file,  protects 
tab  located  at  the  rear  of  the  cassette.  Indicator 
on  console  displays  status. 


3.3.4. 2 Physical 

a.  Height:  6 inches  (15.2  cm) 

b.  Depth;  16  inches  (40.5  cm) 

c.  Temperature;  10°  to  40°  C 

d.  Width;  15-1/2  inches 

e.  Weight;  31  lb  (14  kg) 

f.  Humidity;  Up  to  90%  relative  without  condensation 

g.  Interface;  3 foot  (91.4  cm)  cable  terminated  with  a 54-pin  header  con- 
nector. Mating  connector  shall  be  on  the  CRT  terminal. 
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3. 3.4. 3 Power  Requirements  (Nominal) 

Nominal  power  requirements  of  the  tape  cassette  console  shall  be  as 
follows: 

a.  Line  cord  shall  be  7 feet  (2.13  meters)  long,  3-wire,  fixed  to 
terminal. 

b.  Load-  100  VA  (standby),  130  VA  (one  cassette  forward),  250  VA 
(both  cassettes  rewinding);  115/230  Vac,  50/60  Hz  nominal  input. 
Power  settings: 

(1)  Low:  90  to  110  Vac,  180  to  220  Vac 

(2)  Med:  104  to  126  Vac,  208  to  250  Vac 

(3)  High:  114  to  136  Vac,  224  to  272  Vac 

3.4  HARD  COPY  PRINTER 


3.4.1 


General 


The  printer  unit  shall  be  provided  as  an  accessory  to  the  PARR  terminal, 
and  shall  provide  the  user  with  a choice  of  hard-copy  printing  options  as 
discussed  below. 


3.4.2 


Functional  Description 


3.4.2. 1 On-Line  Mode 


3.4.3 


The  printer  unit  shall  provide  hard  copy,  on  an  8-1/2  inch  paper  roll,  of 
all  data  exchanged  between  the  computer  CPU  and  the  terminal.  Printer 
operation  shall  be  at  the  same  speed  as  the  terminal-eomputer  system, 
i.  e.,  10,  15,  or  30  characters  per  second.  This  mode  shall  not  normally 
be  used,  since  the  speed  of  PARR  operations  is  120  characters  per  second. 


3.4.2.  2 Off-Line  Mode 


The  operator  shall  be  able  to  print  off-line  directly  from  the  terminal  core 
memory.  The  print  function  shall  be  eontrollable  through  software,  or 
simply  by  the  operator  depressing  the  PRINT  key  at  the  terminal  console. 
The  PRINT  key  shall  interlock  with  the  SHIFT  key,  with  both  depressed  to 
initiate  a print  operation.  The  off-line  printing  rate  shall  be  30  characters 
per  second  regardless  of  the  baud  rate  of  the  terminal-computer  network. 
In  the  off-line  mode,  the  operator  shall  be  able  to  select  directly  from  the 
terminal  screen  what  he  wants  printed. 

Software  Control 

The  printer  shall  respond  to  the  following  CPU  commands: 


Command 

a.  On-line 

b.  Off-line 

c.  Print 


Control  Shifted  Period 
Followed  by; 


ASCII  "SO” 
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APPENDIX  A -5 

PARR  COMPUTER  MECHANIZATION  ALTERNATIVES 
1.  INTRODUCTION 

The  Performance  And  Reliability  Reporting  (PARR)  system  was  established  to 
provide  timely,  high  quality  data  on  the  performance,  reliability,  and  other  opera- 
tional aspects  of  the  Torpedo  Mk  48  Weapon  System  and  associated  equipment. 

Inherent  to  the  objective  is  a requirement  to  collect,  store,  and  retrieve  a large 
amount  of  data. 

Mechanization  of  the  PARR  data  system  computer  has  proceeded  from  card- 
oriented  and  batch-operated  to  disk  storage-oriented  and  real-time  operated.  During 
this  transition  the  computer  has  remained  essentially  a single-program  machine, 
with  the  real-time  operation  concept  forcing  commimications  and  application  pro- 
grams to  compete  for  resources.  Program  loading  and  unloading  take  up  a significant 
portion  of  computer  time,  and  terminal  operation  is  slow  when  many  terminals  are 
using  the  system. 

This  study  had  the  purpose  of  examining  the  alternatives  available  at  this  time 
and  in  the  foreseeable  future  to  increase  the  efficiency  of  mechanization  of  the  PARR 
data  system.  The  approach  taken  has  been  to  examine  current  operational  practices 
and  available  commercial  hardware  and  software  to  identify  both  short-term  and 
long-term  alternatives.  Some  alternatives  that  are  probably  unacceptable  have  been 
included  in  order  to  define  clearly  the  limits  and  rationale  of  acceptability.  Decisions 
are  outlined  which,  when  made,  will  provide  the  policy  base  for  development  of  a pro- 
curement specification  for  a PARR  dedicated  computer. 


2.  SUMMARY  AND  CONCLUSIONS 

A wide  selection  of  computer  hardware  and  accessories  is  available  that  allow 
the  input,  storage,  and  retrieval  of  data  in  real  time.  These  items  are  sold  by 
manufacturers  as  part  of  either  original  equipment  manufacturer  (OEM)  or  "turn-key" 
systems.  Software  for  these  computers  are  available  from  both  hardware  and 
software-only  suppliers,  and  from  organizations  that  have  developed  in-house 
applications. 

Few  manufacturers  have  developed  software  for  supporting  data  equipment, 
preferring  to  supply  lower-level  (with  respect  to  COBOL)  assembly  languages,  such 
as  BASIC  and  FORTRAN,  in  which  the  purchaser  can  prepare  his  own  control  pro- 
grams. The  critical  deficiency  in  most  of  the  machines,  as  far  as  PARR  is  concerned, 
is  the  unavailability  of  COBOL  on  small  computers.  While  the  small-batch  models 
from  large  computer  manufacturers  offer  this  ’anguage,  COBOL  compilers  are 
available  on  only  three  types  of  mir  icomputer.  The  degree  of  compliance  with  the 
Navy  COBOL  requirement  in  this  instance  should  be  reviewed. 

An  evolutionary  approach  to  development  of  an  independent  capability  appears 
possible,  but  is  not  immediately  obvious.  That  is,  there  is  no  available  equipment 
that  can  be  configured  in  a minimal  form  as  a preprocessor  or  Input  data  processor, 
and  In  a larger  form  as  a complete  data  management  system.  A stepwise  approach 
from  a communications-oriented  to  a data-oriented  machine  is  possible,  as  is  the 
use  of  a data-oriented  machine  initially  for  communications  purposes. 
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3.  REQUIREMENTS 


PARR  mechanization  requirements  are  discussed  below  in  terms  of  functional, 
hardware,  and  software  categories.  Functional  requirements  are  derived  from 
fxinctions  performed  by  the  present  system;  and  hardware  and  software  requirements 
are  then  derived  from  the  functional  needs.  The  equipment  capabilities  needed  to 
meet  these  requirements  will  also  be  discussed. 


3.1  FUNCTIONAL  REQUIREMENTS 

The  primary  functional  requirements  of  the  PARR  data  system  is  to  support  a 
variety  of  data  input  and  retrieval  demands  simultaneously,  providing  up-to-date, 
useful  information  in  display  or  printed  form,  both  periodically  and  on  request.  This 
requirement  identifies  the  uniqueness  of  the  PARR  system  relative  to  the  typical 
airline  reservation  or  business  system,  or  commercial  time-sharing  computer  net- 
work. In  the  PARR  system,  many  remote  terminals  perform  essentially  the  same 
function  and  require  support  by  only  one  program,  which  may  be  written  in  machine 
language  and  optimized  for  efficiency.  In  the  latter  systems,  the  terminals  all  con- 
trol their  own  programs,  performing  different  functions;  and  require  support  by 
compilers  and  a flexible  operating  system,  one  that  can  accommodate  many  - imul- 
taneous  programs. 

In  the  PARR  data  system,  input  and  file  maintenance  use  from  5 to  10  programs, 
each  tailored  for  a specific  application.  More  than  20  retrieval  programs  may  be 
available  in  the  near  future,  each  also  formatted  to  provide  support  for  a specific 
application.  All  programs  require  maintenance  periodically,  so  must  be  written  in  a 
high-level  language.  Further,  most  terminals  will  be  used  for  both  data  input  and 
retrieval,  thereby  requiring  access  to  both  sets  of  programs. 

The  following  functions  are  required  for  the  PARR  data  system: 

a.  Real-time  system  supervision 

b.  Permanent  storage  of  data  on  magnetic  tape 

c.  Temporary  storage  of  a significant  portion  of  the  data  file  on  magnetic  disk 

d.  Tape  file  maintenance 

e.  Disk  file  maintenance 

f.  Disk/tape  file  loading  and  unloading 

g.  Data  management  control  capability 

h.  COBOL  programming  language  support 

i.  Assembly  language  programming  support 

j.  Multiple  simultaneous  application  support 

k.  Report  printing 
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l.  Local  terminal  support 

m.  Remote  terminal  support 

n.  Data  input  to  mass  storage 

o.  Data  retrieval  from  mass  storage 

Combinations  of  these  functions  will  be  made  in  order  to  implement  the  follow- 
ing configuration  capabilities: 

a.  Communications  concentration 

b.  Data  preprocessing 

c.  Small  data  system  with  current  data  only 

d.  Complete  data  system 

3.2  HARDWARE  REQUIREMENTS 

The  major  hardware  elements  needed  to  fulfill  the  functional  requirements  of 
the  PARR  data  system  are  the  central  processing  unit  (CPU),  storage  facility,  com- 
munication facility,  and  printing  facility. 

3.2.1  Central  Processing  Unit 

The  CPU  provides  real-time  supervision  over  that  portion  of  the  data  system 
operations  being  managed  at  the  site  where  the  CPU  is  located.  Significant  features 
of  a CPU  performing  real-time  functions  are: 

a.  Real-time  operating  system 

b.  Real-time  clock  available  to  software 

c.  Memory  protection 

d.  Instruction  relocation 

e.  Hardware  interrupts 

f.  Input/output  channels 

g.  Priority  interrupt  structure 

h.  Paging  or  virtual  memory 

i.  Direct  memory  addressing 

j.  Fast  register  status  storage 


A-5-3 


These  features  allow  the  CPU  to  maintain  control  of  operations  and  respond  to 
the  demands  made  upon  it  by  peripheral  equipment. 

3.2.2  Storage  Facility 

Temporary  and  permanent  storage  hardware  accessible  by  the  CPU  in  the  form 
of  core,  disk,  and  tape  are  necessary  to  provide  data  storage  functions.  This  may  be 
short-term  storage  while  the  data  is  enroute  to  the  central  computer,  or  it  may  be 
the  complete  file. 

Significant  features  affecting  real-time  operation  are  core  size  and  speed 
relative  to  the  intended  application.  Limited  core  will  require  loading  of  only  por- 
tions of  an  executing  program,  with  other  portions  on  disk-stored  pages  saved  for 
loading  when  needed.  Therefore  a minimum  of  64,000  bytes  of  core  or  equivalent 
fast-access  storage  is  required. 

Program  page  swapping  can  consume  a significant  amount  of  time.  Small  and 
slow-access  disk  storage  will  slow  down  the  paging  process  and  impede  access  to 
stored  data.  Therefore  a fixed-head  disk  of  2 million-byte  capacity  is  required. 

Considerable  physical  movement  of  disk  arms  may  be  required  in  random- 
access  disk  storage.  However  the  entire  data  file  must  be  stored  with  room  for 
5 year's  growth,  and  thus  moving-head  disk  storage  of  150  million  char-icters  is 
required  (100  million  characters  currently  and  growing  at  the  rate  of  10  million 
characters  per  year). 

3.2.3  Communication  Facility 

The  communication  facility  must  include  hardware  for  handling  local  terminals, 
remote  terminals,  and  intersite  communications.  A minimum  of  15  ports  is  required 
(see  PARR  System  Plan,  Section  5.2). 

Local  terminals  are  those  directly  connected  to  the  computer,  with  no  use  of 
commercial  or  private  telephone  lines.  At  least  500  feet  of  separation  from  the 
central  computer  should  be  allowable  in  the  local  terminals. 

Remote  terminals  are  those  located  anywhere  in  the  world  having  access  to  the 
computer  through  telephone  lines.  The  current  PARR  data  system  operating  speeds 
are  10  and  120  characters  per  second. 

Intersite  commvmication  is  over  short  distance  (about  2,000  feet)  and  long 
distance  (thousands  of  miles).  Over  the  short  distance,  from  the  PARR  office  to  the 
data  processing  center,  either  multiple  terminal  or  single  preprocessor  channels  are 
needed.  The  long  distance  intersite  link,  for  example  from  Keyport  to  Washington, 

D.  C.  or  Hawaii,  would  require  at  least  one  high-speed  dedicated  channel. 

3.2.4  Printing  Facility 

Because  of  the  large  volume  of  printed  reports  generated  by  the  PARR  system, 
a high-speed  printing  facility  is  required  (at  least  600  lines  per  minute). 
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3.3  SOFTWARE  REQUIREMENTS 


PARR  fxmctions  that  depend  upon  software  for  realization  are  real-time  system 
supervision,  data  management  control,  COBOL  program  language  support,  and 
assembly  language  support.  The  most  critical  of  these  functions  is  COBOL  support, 
since  most  small  computers  already  provide  high-level  language  support  in  BASIC, 

FORTRAN,  ALGOL,  or  RPG.  In  any  event,  some  high-level  language  is  required 
for  program  preparation. 

Assembly  language  programming  capability  is  needed  for  programming  the 
specific  interfacing  terminals  of  remote  processors,  including  the  Honeywell  com-  - 

puter.  In  most  cases,  it  should  be  easier  to  modify  the  remote  processors. 

! 

4.  CAPABILITIES 

The  previous  section  addressed  PARR  data  system  requirements  independently 
of  whether  they  could  be  realized  in  a practical  configuration.  In  this  section,  the 
capabilities  of  available  hardware  and  software  are  summarized  in  the  areas  where 
PARR  requirements  have  been  stated- 


4.1  HARDWARE  CAPABILITIES 

Central  processing  units  within  the  scope  of  the  PARR  requirements  are 
generally  classified  as  minicomputers.  However  a distinction  between  the  two  is 
being  drawn  with  increasing  word  size,  memory  capacity,  and  processing  sophis- 
tication of  computers.  A minicomputer  has  historically  been  characterized  by  small 
physical  size,  processing  capability,  configuration  availability,  software  support, 
word  length,  cycle  rate,  and  cost.  The  direction  of  evolution  has  been  toward  a con- 
tinuing reduction  of  these  features.  In  the  early  1970's,  word  lengths  decreased  from 
16  to  eight  bits,  cycle  rates  from  two  to  one  microsecond,  and  costs  from  $20,000  to 
$15,000.  In  the  last  two  years,  some  manufacturers  have  increased  word  size  to 
32  bits,  retained  a less-than-one-microsecond  cycle  time,  increased  overall  sophis- 
tication, and  raised  the  cost  to  $30,000  or  more.  A wide  variety  of  peripherals  is 
now  available,  including  50,000,000-character  disk  drives  and  600  line-per-minute 
printers. 

I Table  1 summarizes  operational  characteristics  of  a cross-section  of  small 

computers.  This  information  was  obtained  from  published  surveys  and  manufacturer 
interviews. 

Storage  devices  are  available  in  a variety  of  forms.  Magnetic  core  is  generally 
offered  in  4,000  or  8,000  character  increments  to  a total  of  128,000  characters. 

Disk  storage  is  either  fixed-head,  with  a 10-microsecond  access  time;  or  moving- 
head,  with  a 50-  to  100-microsecond  access  time.  Fixed-head  disks  hold  less  than 
500,000  characters,  while  moving-head  disk  packs  hold  up  to  200  million  characters 
per  drive.  The  advantage  of  the  larger  disk  size  is  the  lower  cost  per  bit  of  storage. 
For  example,  increasing  drive  size  from  2. 5 million  to  50  million  bits  could  reduce 
the  cost  per  bit  stored  from  $5  to  50/.  Of  course,  the  drive  utilization  is  also  an 
important  factor.  The  large  size  of  the  PARR  files  and  the  scope  of  requests  from 
those  files  would  seem  to  dictate  a relatively  large,  well  organized  moving-head  disk. 
Considerations  of  reliability  could  dictate  two  smaller  units. 
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(1)  All  have  real-time  operations,  data  character  (byte)  moving  instructions,  real-time  clock,  and  range  of 
peripherals. 


Communications  capabilities  are  generally  characterized  by  speed  and 
flexibility.  PARR  terminals  are  presently  connected  to  the  central  site  by  a switched 
telephone  network  at  120  characters  per  second  (cps).  This  allows  a low  error  rate 
and  flexibility  of  interconnection,  with  message  times  of  less  than  10  seconds.  More 
terminals  can  be  accommodated  by  adding  more  off-line  capability  so  that  actual 
telephone  call  time  is  shortened.  Five  computer  lines  could  then,  for  example, 
accommodate  ten  terminals. 

Putting  more  than  one  terminal  on  a line  would  mean  changing  the  computer 
communications  controller  (e.  g. , to  the  Hazeltine  3000)  to  provide  for  addressing  of 
terminals.  Another  alternative  is  to  use  a cluster  of  terminals  under  one  master 
control,  such  as  the  Hone5rwell  MTS  7500,  and  changing  the  Honeywell  controller  to 
handle  this  configuration.  As  another  example,  a terminal  tnmking  feature  is  an 
option  of  the  Mohawk  2400;  data  terminals  can  be  located  up  to  2000  feet  on  shielded 
cable  from  the  Mohawk  location. 

Communications  speed  in  the  Honeywell  is  limited  to  2400  bps  (300  cps)  per  line 
unless  the  DATANET  2000  is  used  as  the  communications  processor.  In  that  case  the 
upper  limit  is  10,800  bps.  A concentrator  in  the  PARR  office  would  commimicate 
\»dth  the  Honeyw'ell  over  several  dedicated  2400-bps  lines  with  Bell  type  201  modems 
The  number  of  lines  needed  would  depend  upon  the  total  traffic  load.  In  all  probability, 
considering  the  inherent  delays  in  the  Honeywell  processing,  only  one  line  would  be 
required  for  eight  to  ten  terminals.  This  line  would  accommodate  35  to  45  messages 
per  hour. 

5.  MECHANIZATION  ALTERNATIVES 

The  alternatives  for  mechanizing  the  PARR  data  system  to  increase  its 
efficiency  will  now  be  discussed  in  terms  of  the  configuration  capabilities  outlined  in 
Section  3.  Table  2 shows  these  capabilities  and  the  relative  size  or  type  of  hardware 
and  software  available  to  implement  the  configuration. 


TABLE  2.  PARR  CONFIGURATION  CAPABILITY  ALTERNATIVES 


Configuration 

Capability 

Processor 

Storage 

Printer/Copier 

Software 

Concentrate 

Commvmications 

Small 

Small 

None 

Assembly 

Preprocess  Data 

Medium 

Medium 

None 

Package 

Provide  Small 

Data  System 

Medium 

Large 

Yes 

COBOL 

Provide  Complete 
Data  System 

Large 

Very 

large 

Yes 

COBOL 
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Communications  concentration  is  a relatively  small  task  rcKiuiring  a small 
processor,  small  storage,  assembly  language  software,  and  no  peripherals.  This 
would  allow  several  terminals  to  access  the  computer  over  the  same  telephone  line. 

Preprocessing  of  data  requires  a slightly  larger  processor  to  make  decisions 
about  fields  and  their  validity.  A moderate  amount  of  storage  would  be  needed  if  the 
data  were  to  be  collected  on  a tape  or  disk.  The  data  preprocessor  software  could  be 
a data  management  package,  allowing  specifieation  of  the  validity  requirements  for 
each  field. 

A small  data  system  would  include  some  or  all  the  hardware  and  software  nec- 
essary to  implement  the  system,  but  only  enough  storage  to  provide  for  a small 
amount  of  data  (say  six  months).  A complete  data  system  would  include  enough  com- 
puter power  and  addressable  storage  to  accommodate  the  current  system  and  provide 
for  expected  growth  over  the  next  two  years. 


6.  ACQUISITION  ALTERNATIVES 

Table  3 shows,  in  matrix  form,  the  nine  alternatives  for  procuring  data- 
processing  systems.  Acquisition  sources  are  1)  a manufacturer,  2)  an  original 
equipment  manufacturer  (OEM)  who  assembles  components,  and  3)  a turn-key  sup- 
plier who  provides  a working  total  system.  Items  they  can  provide  are  divid  id  into 
the  collective  categories  of  components,  all  hardware,  hardware  and  software,  and 
hardware  with  a data  management  package. 


TABLE  3.  ALTERNATIVES  OF  DATA  SYSTEM  ACQUISITION 


Source 

Item 

Manufacturer 

OEM 

Turn-Key 

Components 

1 

X 

X 

Hardware 

2 

3 

X 

Hardware  & Software 

4 

5 

f> 

Hardware  & Data  Mgmt. 
Package 

7 

8 

9 

Procuring  components  from  a variety  of  manufacturers  (alternative  1)  is 
probably  the  most  common  approach  in  developing  data  systems  of  this  type. 
Standardization  is  such  that  small  manufacturers  can  specialize  on  one  peripheral 
type  and  sell  it  both  openly  on  the  market  and  to  original  equipment  manufacturers. 
While  this  approach  would  be  economical  for  a single-location  commercial  business, 
it  is  not  appealing  to  a widespread  network  such  as  PARR.  If  it  were  considered  for 
use  only  at  NTS,  assurances  from  the  manufacturer  would  be  necessary  concerning 
maintenance  support  at  the  station.  In  this  alternative,  the  software  would  have  to  be 
developed  by  the  station  from  an  assembly -language  or  FORTRAN  compiler. 
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Procuring  all  hardware  from  a sinRle  manufacturer  (alternative  2)  is  unlikely 
since  most  suppliei’s  are  OEMs  for  only  a portion  of  a system.  For  example, 
Honeywell's  MTS  7500  is  a Honeywell  DATA  POINT  2200/3300  combination  with 
custom  software  to  accomplish  the  multifunction  terminal  operation.  An  OEM,  on  the 
other  hand,  generally  manufactures  one  or  several  segments  of  a system  and  pack- 
ages the  other  segments  under  his  name  (alternative  3).  In  so  doing,  the  manu- 
facturer assumes  the  responsibility  for  the  support  of  the  total  system.  For  example 
the  Hazeltine  printer  is  made  by  Texas  Instruments  and  supported  by  Hazeltine. 

These  alternatives  again  would  require  the  complete  development  of  software  by  NTS, 
probably  in  assembly  language. 

There  are  further  alternatives  to  procuring  combinations  of  hardware  and  soft- 
ware. Again  a single  manufacturer  (alternative  4),  unless  it  were  IBM,  could  not 
supply  both  portions.  The  OEM  goes  beyond  supplying  the  hardware  and  adds  soft- 
ware of  the  types  he  is  probably  most  competent  to  prepare  (alternative  5).  Only  the 
largest  OEMs  supply  the  complete  line  of  hardware  and  software,  including  high-spee<i 
line  printers  and  COBOL.  Turn-key  system  suppliers  (alternative  6)  have  software 
tailored  to  specific  operations  such  as  general  ledger  or  commercial  BASIC  time- 
sharing. If  PARR  applications  were  such  that  they  would  not  change  with  time,  then 
a turn-key  system  might  be  appropriate.  These  applications  will  change,  how'ever, 
and  PARR  will  continue  to  write  programs  to  cope  with  the  changes.  From  this  point 
of  view,  then,  a turn-key  procurement  is  probably  not  advisable. 

Hardware  and  data  management  package  could  be  obtained  from  all  three 
sources.  An  example  of  this  alternative  would  be  the  Mohawk  2400.  With  one  set  of 
options  this  system  supports  remote  terminals  in  a key-disk  or  key-tape  mode.  The 
system  is  composed  of  a minicomputer,  storage,  terminals  and  a data  management 
package  of  software.  Whether  procured  from  a manufacturer  (alternative  7),  OEM  (B), 
or  turn-key  source  (9),  the  package  approach  leaves  limited  flexibility.  In  some 
cases,  as  with  Cincom  System’s  "Total",  MRI  Corporation's  "System  2000",  and 
other  general  data  base  management  systems,  flexibility  is  great.  The  flexibility  of 
the  offering  is  therefore  the  question  of  interest,  and  these  alternatives  should  be 
kept  open  for  consideration. 
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APPENDIX  A-6 

SPECIFICATION  FOR  PARR  INTERFACE  UNIl 


1.0  SCOPE 

This  specification  describes  the  functional,  physical,  and  electrical 
characteristics  of  an  interface  unit  to  be  used  with  remote  terminals  of  the 
Performance  and  Reliability  Reporting  (PARR)  network  when  operating  on 
the  Automatic  Voice  Network  (AUTOVON).  The  purpose  of  this  device  is 
to  provide  automatic  disconnection  of  the  terminal  in  the  event  of  inactivity 
for  a specified  period  of  time.  Secondarily,  the  device  will  indicate  the 
presence  of  electrical  signals  at  the  interface. 

2.0  APPLICABLE  DOCUMENTS 

The  following  documents  form  a part  of  this  specification  to  the  extent  that 
they  are  referenced  herein: 

a.  JCS  Memorandum  of  Policy  No.  151,  "Autovon  Operation  Criteria" 

b.  ElA  Standard  RS-232C,  Interface  Between  Data  Terminal  Equipment 
and  Data  Communication  Equipment  Employing  Serial  Binary  Data 
Interchange 

3.0  REQUIREMENTS 

3.1  EQUIPMENT  DESCRIPTION 

The  PARR-AUTOVON  Interface  Unit  (PAIU)  is  a portable  device  that  can  be 
connected  physically  and  electrically  to  the  interface  between  the  PARR  ter- 
minal and  a telephone  company  modem.  The  PAIU  satisfies  the  requirements 
(para  41)  of  JCS  Memo  151  (reference  a)  for  automatically  limiting  the  use 
of  the  terminal  on  AUTOVON  circuits.  In  addition,  it  monitors  the  presence 
of  interface  signals  and  provides  a test  plug  for  signal  injection  and  evaluation. 

3.1.1  Interface  Definition 

Figure  1 is  a simplified  drawing  of  the  elements  of  a PARR  remote  termi- 
nal connected  to  the  central  computer  site.  Telephone-line  equipment  may 
be  either  commercial  or  AUTOVON-dialed  networks.  Interface  charac- 
teristics of  the  terminal  and  modem  are  defined  by  EIA  Standard  RS-232C 
(reference  b). 

3.1.2  Hardware  Definition 


The  hardware  shown  in  the  PARR  system  diagram  of  Figure  1 consists  of: 

a.  The  PARR  terminal,  including  keyboard,  display,  printer,  and  cas- 
sette units 
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Figure  1.  Simplified  Interface  Diagram 


b.  The  PAIU,  defined  by  this  specification 

c.  A modem  (Bell  type  202C)  operating  at  1200  bits  per  second. 

All  connectors  are  25-pin,  RS-232C  compatible  plugs  (Cinch  or  Cannon  Co. 
type  DB25P  or  equivalent)  or  sockets  (Cinch  or  Cannon  Co.  type  DP25S  or 
equivalent)  as  appropriate. 

3.2  CHARACTERISTICS 


3.2.1  Functional 

The  PAIU  performs  two  principal  functions;  signal  monitoring  and  auto- 
matic disconnect.  A general  functional  block  diagram  is  shown  in  Fig- 
ure 2. 


3. 2. 1.1 


lal  Monitoring 


At  the  line  speed  being  used  in  the  PARR  network,  1200  bps,  only  a half- 
duplex signal  can  generally  be  transmitted  or  received  at  one  time  over  a 
dial-up  line.  Under  this  condition,  data  transmission,  line  control,  and 
equipment  status  signals  can  be  profitably  monitored  to  indicate  source  of 
trouble  in  cases  of  communication  problems.  The  following  circuits  of  the 
interface  shall  be  monitored  for  signals  between  +3  and  +25  volts  with  LED 
or  equivalent  indicator  lamps; 


Circuit 

Pin 

Name 

BA 

2 

Send  Data 

BB 

3 

Receive  Data 

CA 

4 

Request  to  Send 

CB 

5 

Clear  to  Send 

CC 

6 

Data  Set  Ready 

CF 

8 

Carrier  Detect 

CD 

20 

Data  Terminal  Ready 

Impedance  to  the  data  circuit  shall  be  greater  than  30,000  ohms. 
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3.2.2 


Terminal 

Connector 


Modem 

Connector 


Monitor 


Timer 


Test 

Connector 


Power  Supply 


Figure  2.  General  Functional  Block  Diagram  of  PAIU 


In  addition  to  lamp  monitoring,  a test  connector  shall  be  provided  to  allow 
access  to  data  circuits  BA  and  BB.  It  shall  be  possible  to  transmit  to  or 
receive  from  the  terminal  or  modem. 


3. 2.1. 2 Timed  Disconnect 


For  AUTOVON  lines,  JCS  Memo  151  (para.  4i)  requires  the  automatic  dis- 
connect of  a data  terminal  to  "free  the  circuit  after  the  device  is  inactive 
for  a period  of  one  minute".  This  function  shall  be  accomplished  in  the 
PAIU  by  a timer  that  will  be  started  when  a connection  is  established,  and 
then  reset  by  data  transfer  in  either  the  send  or  receive  directions.  At  the 
completion  of  the  timed  interval,  circuit  CD,  "Data  Terminal  Ready",  shall 
be  turned  off.  When  the  call  is  disconnected  as  indicated  by  circuit  CC 
being  turned  off,  CD  shall  be  returned  to  "on"  for  the  next  call.  An  over- 
ride switch  shall  be  provided  for  use  of  the  terminal  on  non-AUTOVON 
circuits.  Figure  3 illustrates  the  required  PAIU  switching  logic. 

Physical 


3. 2. 2. 1 Transportability 


The  PAIU  shall  be  packaged  in  one  case  and  designed  to  be  portable. 


3.2. 2.  2 Durability 


3. 2. 2. 3 


The  PAIU  shall  be  packaged  to  withstand  normal  handling  in  on-site  ^’pera- 
ation  such  as  may  be  encountered  when  it  is  operated  with  the  PARR  termi- 
nal. The  PAIU  shall  withstand  a drop  from  a height  of  three  feet  without 
impairment  of  functional  characteristics. 


The  PAIU  shall  use  no  internal  secondary  power  greater  than  40  volts.  The 
primary  ac  power  circuit  shall  be  fuse-protected  and  frame-grounded  with  a 
third  conductor. 
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b.  Several  messages  without  EOT,  simulating  tape,  or  printer  control, 
can  be  sent  to  the  terminal,  thereby  resetting  the  timer  on  each 
message. 

c.  Disconnecting  the  controlling  terminal  telephone  circuit  will  cause  the 
remote  terminal  to  hang  up  in  approximately  one  minute. 

5.0  PREPARATION  FOR  DELIVERY 

The  PAIU  shall  be  packed  in  a manner  that  will  provide  adequate  protection 
during  normal  freight  transfer. 

6.0  NOTES 


6. 1 DEFINITIONS 

The  definitions  of  RS-232C  (reference  b)  apply  to  undefined  terms  of  this 
specification. 


A-6-5/A-6-6 


APPENDIX  A -7 

DATA  PORT  EFFICIENCY  STUDY 


1 


Under  task  10m,  a study  was  conducted  of  PARR  data  port  efficiency  and 
recommendations  were  made  for  increasing  it.  Five  alternative  equipment  configura- 
tions have  been  identified  that  would  enhance  data-port  efficiency  by  the  connection  of 
either  1)  multiple  terminals  to  one  telephone  line  for  access  to  one  computer  port,  or 
2)  more  than  one  telephone  line  in  call  sequence  order  to  one  or  more  computer  ports. 
This  report  gives  an  analysis  of  present  telephone  traffic  and  discusses  the 
alternatives  for  handling  it  more  efficiently. 


1.  ANALYSIS  OF  TELEPHONE  TRAFFIC 

The  reliability  block  diagram  for  the  present  PARR  office  terminals  is  shown 
below. 


I 


•1 

!i 

■| 

[i 
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li 
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Terminals 


CRT 


MTC 


Dial 

HCP  Modem  Network 


Modem  Port  Computer 


As  indicated  in  the  diagram,  a great  deal  of  redundancy  is  available,  providing  for 
graceful  degradation  of  performance  as  individual  equipments  fail  and  are  slowly 
repaired. 

A group  of  five  terminals,  operating  twenty  8-hour  days  per  month  at  an 
effective  production  rate  of  one  character  per  second  at  each  terminal,  produces: 
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or  36,000  card  imaRes  per  month.  This  theoretical  value  is  in  fjood  aKrecment  with 
the  40,000  to  60,000  card  images  actually  produced  unrier  conditions  and  operating 
procedures  at  the  time  of  this  study  (1974).  The  true  capability,  however,  may  be 
two  to  three  times  the  present  rate  (one  character  per  second)  because  of  the 
advanced  editing  characteristics  of  the  terminal  and  real  operator  keying  ability.  That 
is,  the  five  terminals  could  probably  process  collectively  some  100,000  to  160,000 
card  images  per  month. 

With  reference  to  the  dial  network  communications  lines,  one  line  can  handle  a 
throughput  of 


1 line 


/120  char. 
\ second 


3600  X 8 X 20 


secondsWl  card  imr.ge\ 
month  j\  80  char.  / 


or  430,000  card  images  per  month  per  line,  considering  a 60^,'  utilization  of  the  line. 

It  is  evident,  therefore,  that  the  current  system  concept  emphasizes  simplicity, 
low  cost,  reliability,  and  availability  at  the  expense  of  performance  (throughput), 
thereby  operating  at  a low  level  of  efficiency.  An  increase  in  efficiency  is  possible  by 
several  routes,  each  involving  an  increase  in  system  cost  (dollar  and  effort)  and  a 
decrease  in  reliability/availability.  In  all  cases,  efficiency  is  increased  by  sharing 
ports  among  terminals  to  achieve  greater  utilization  of  communication  time.  Lowest 
efficiency  would  be  with  each  terminal  occupying  one  port  on  a dedicated  line,  using  it 
only  when  communication  is  necessary.  Highest  efficiency  would  be  with  a large 
enough  group  of  terminals  using  one  line  that  there  would  always  be  a queue  waiting  for 
service,  and  therefore  the  line  would  always  be  in  use.  The  current  operation  dial-up 
lines  is  between  these  efficiency  extremes  since  all  ports  may  be  accessed  by  all 
terminals.  In  fact,  a high  efficiency  could  be  attained  by  using  only  remote-batch  or 
remote-job-entry  techniques  with  all  input  from  and  output  to  the  tape  cassette. 


2.  ALTERNATIVE  CONFIGURATIONS 

Methods  for  increasing  the  performance  and  efficiency  of  the  data  port  include 
the  following: 

a.  Adding  more  terminals  of  a similar  t3q3e  to  increase  performance  and 
require  remote  job  entry  (RJE)  operations; 

b.  Enhancing  current  port  capability  on  the  central  computer  with  a port 
expander  to  provide  rapid  switching  between  waiting  calls; 

c.  Adding  a cluster  controller  to  the  present  terminals  to  control 
terminal  access  to  the  computer; 

d.  Changing  to  computer-polled  tex'minals; 

e.  Changing  to  a cluster  of  polled  terminals  with  polling  cluster  controller. 

Each  of  these  alternatives  will  be  briefly  discussed  and  evaluated. 

i 
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First,  the  current  concept  could  be  continued  with  the  addition  of  more 
terminals  of  the  same  or  similar  type.  As  has  been  noted,  any  desired  Increase  in 
efficiency  could  be  obtained  by  performing  more  operations  off-line  in  an  RJE  environ- 
ment. (It  might  be  pointed  out  that  the  Honeywell  computer  w’ould  operate  more 
efficiently  in  this  mode  since  it  was  designed  for  this  t5T)e  of  operation.)  The  only 
operational  procedure  now  requiring  a continuous  on-line  terminal  is  that  of  modifi- 
cation. This  requirement  could  be  changed  by  initiating  a procedure  that  would  allow 
a list  of  PARR  forms  needing  modification  to  be  requested  and  put  on  tape  cassette. 
Modification  would  be  performed  off-line  from  one  cassette  to  the  other,  and  the 
modified  data  input  from  the  second  cassette.  Each  time  a terminal  operator  wanted 
to  use  a line,  the  operator  would  dial  the  conne'  tion  and  stay  on-line  only  until  the 
tape  operations  were  finished.  While  this  procedure  would  produce  a high  communi- 
cations efficiency,  it  would  place  a greater  load  on  the  terminal  operator. 

More  ports  with  a flexibility  in  speed  and  interconnection  could  be  achieved  with 
the  use  of  a port  expander  or  selector  at  the  central  computer.  This  device,  an  inter- 
face between  the  dedicated  or  switched  modems  and  the  computer  ports,  functions  as 
both  a rotary  switch  and  port  interconnector.  Manufacturers  of  such  devices  include 
Infotron  Systems  Corp.  and  Data  Products/Telecommunications  Division.  Infotron's 
Timeline  450,  in  its  basic  configuration,  can  be  used  to  interface  16  lines  with  eight 
ports;  and  has  an  ultimate  capability  of  interfacing  254  lines  with  124  ports.  The  port 
expander  scans  the  modem  lines  (ring  indicator)  until  an  access  request  is  found;  and 
then  scans  the  ports  until  it  finds  one  of  the  proper  type  available.  The  port  and  line 
are  connected  and  activity  monitored  until  the  call  is  over,  upon  which  it  disconnects 
the  line  and  makes  the  port  available  for  another  call.  In  addition,  most  port 
expanders  continually  provide  status  indication  and  diagnostics.  A device  of  this  type 
is  highly  recommended  for  consideration  as  the  next  step  in  PARR  communication 
enhancement  beyond  the  front-end  planned  for  installation  early  in  1975. 

The  last  three  approaches  (c,  d,  and  e,  above)  involve  the  use  of  some  form  of 
polling.  In  all  cases,  the  poller  is  a node  or  bottleneck  in  the  network  through  which 
all  traffic  must  pass  and  on  which  all  operation  is  dependent.  The  reliability  of  the 
polling  device  is  therefore  important. 

Adding  a cluster  controller  to  the  present  terminals  consists  of  placing  a con- 
tention resolution  device  or  distributor  between  one  modem  and  a group  or  cluster  of 
terminals.  When  one  terminal  wants  to  use  the  line,  it  requests  it.  If  the  line  is  free, 
the  distributor  connects  the  terminal  to  the  line  modem  for  transmission  of  one 
message,  at  which  time  the  distributor  disconnects  the  terminal  and  resumes  scan- 
ning for  access  requests.  While  one  terminal  is  connected,  the  others  are  denied  the 
clear-to-send  signal  so  that  they  will  not  interfere.  The  main  advantage  of  this 
device  over  other,  more  sophisticated  types  is  its  simplicity  and  reliability.  Opera- 
tor control  is  uncomplicated,  involving  no  new  switches  or  lights.  One  disadvantage 
is  that  during  a long  search  time,  while  the  terminal  is  waiting  for  a reply  from  the 
computer,  no  other  terminals  may  use  the  line.  Another  disadvantage  is  that  cassette 
operations  would  not  be  possible. 

A change  of  terminals  to  one  Intelligent  enough  to  be  polled  by  the  computer  or 
the  front-end  would  transfer  the  control  of  commimications  from  the  terminal  to  the 
computer.  This  Intelligence  implies  some  preconceived  notion  of  the  manner  in  which 
the  terminal  is  to  be  used  since  it  is  the  procedure  that  is  programmed  into  the  termi- 
nal. Some  of  the  most  common  notions  are  that  a human  operator  is  always  present, 
since  a display  screen  is  being  used;  only  one  page  is  sent  in  one  message,  since  the 
operator  must  decide  what  to  do  with  a page  or  it  will  be  destroyed  by  overwriting; 
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and  control  of  peripherals  such  as  the  tape  cassettes  and  printer  are  at  the 
operator's  option,  and  not  available  to  the  computer.  In  a manner  similar  to  that  of 
the  above-described  cluster-controlled  terminal,  an  operator  prepares  a message  on 
the  screen  and  requests  to  be  polled.  At  the  next  polling  cycle  the  computer  accepts 
the  message  and  prepares  the  terminal  to  receive  a response.  When  the  response  is 
ready,  the  computer  sends  it  to  the  terminal.  While  one  terminal  is  sending  or 
receiving,  all  others  are  inhibited;  however,  between  the  input  and  output  messages 
at  one  terminal,  the  computer  may  exchange  messages  with  other  terminals.  There 
is  provision  for  character  and  message  parity  checking,  automatic  retransmission  of 
bad  messages,  and  automatic  recovery  from  undefined  situations. 

Advantages  of  pollable  terminals  are  realized  when  there  are  enough  terminals 
to  maintain  a high  level  of  traffic  flow  at  all  times.  Then  the  communications 
efficiency  may  be  kept  high.  Disadvantages  include  the  special  computer  program- 
ming needed  to  support  polling,  and  the  dependence  on  computer  reliability  for  con- 
tinued operations. 

The  two  concepts  of  cluster  and  polled  operation  can  be  combined,  with  the 
controller  doing  the  polling  and  controlling  the  terminals  in  the  cluster.  At  a low 
level  of  intelligence  the  controller  can  only  maintain  communications,  but  with  addi- 
tional capability  can  perform  error  checking  as  well.  In  most  configurations,  for 
example  the  Honeywell  MTS  7500,  tape  cassettes  and  disk  storage  are  available  to 
continue  operations  when  the  central  computer  fails.  After  messages  are  received 
and  stored  by  the  controller,  it  builds  a queue  of  the  messages  and  transmits  them  to 
the  central  computer.  When  responses  are  received,  they  are  routed  in  the  same 
manner  back  to  the  requesting  terminal.  The  only  central  computer  programming 
necessary  is  the  tracking  of  messages  by  terminal  address.  A standard  2000  bit-per- 
second  interface  can  be  used  between  the  controller  and  the  central  computer.  Inter- 
face characteristics  would  be  the  same  for  both  the  Honeywell  286  and  the  DATANET 
2000  communications  processors. 


3.  COST/EFFICIENCY  CONSIDERATIONS 

Efficiency  and  cost  are  the  major  factors  to  be  considered  in  selecting  the  most 
desirable  alternative  for  increasing  PARR  data  port  efficiency. 

Reliability  is  a major  factor  affecting  efficiency.  Independent  operation  may  be 
sustained  when  the  central  computer  fails;  but  without  a backup  controller,  operation 
is  now  dependent  upon  the  controller.  Adequate  provision  for  spare  parts  and  service 
must  be  assured  when  this  approach  is  used. 

Costs  can  range  from  less  than  $36, 000  for  a contention  controller  to  more 
than  $50,000  for  a terminal  cluster  with  polling.  The  current  level  of  cost  for  five 
terminals  is  $35,000  (based  on  a value  of  $7,000  per  terminal  set  including  display, 
tape  cassette,  and  printer). 

For  the  first  alternative,  adding  terminals,  costs  increase  in  increments  of 
$7,000  to  $42,000,  then  $49,000,  etc.  The  second  alternative,  adding  a port 
expander,  would  cost  approximately  $5,000,  making  a total  of  $40,000.  The  third 
alternative,  cluster  terminals,  would  range  in  cost  from  $13,000  to  $36,000  depend- 
ing on  the  number  of  cassettes  and  printers  used  with  the  cluster.  The  lower  figure 
is  for  display  terminals  only.  The  fourth  alternative,  polling  terminals,  would  range 
in  cost  from  $15,000  to  $37,000,  also  depending  on  the  peripheral  equipment.  The 
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fifth  alternative,  polling  cluster  terminals,  would  have  a base  cost  of  approximately 
$40, 000  for  a five-terminal  system  with  a completely  redundant  controller  adding 
$13,000  to  the  price.  The  redundant  controller  could  be  used  for  a variety  of  small 
computational  tasks  during  its  standby  status. 

In  summary,  the  lowest  cost  and  lowest  performance  alternative  is  the  cluster 
terminal  set  costing  about  $13,000.  This  configuration  would  increase  communication 
efficiency  at  the  cost  of  system  reliability  and  local  recording/printing  capability. 

The  highest  cost  and  highest  performance  alternative  is  the  polling  cluster  terminal 
set  costing  about  $40,000.  The  latter  alternative  offers  a significant  increase  in  sys- 
tem efficiency  at  a nominal  increase  in  cost,  and  is  recommended. 


